I am running the test script from GitHub, and I can only open the device as root.
While calling hid_enumerate(0x0, 0x0), it works in user mode.
My udev rule looks like this:
SUBSYSTEM=="usb", ATTRS{idVendor}=="1a86", ATTR{idProduct}=="e008",
MODE="0666"
The rule is working because I can run he2325u_pyusb in user mode.
Disabling this rule, the script runs only with root rights.
How can I access the device in user mode?
ok, I could fix the problem
I changed the udev rules like this:
SUBSYSTEM=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="e008",
MODE="0666" KERNEL=="hidraw*",ATTRS{busnum}=="2",
ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="e008", MODE="0666",
GROUP="users"
The very important thing was to append a * at the end of the KERNEL parameter hidraw*.
Related
I'm running tests with the gcloud datastore emulator for node.
I want to reset the db before each test.
Is there a quick way like a 'drop' command or something I can use in a beforeEach block ?
Just simply remove the db file. Usually, it is ~/.config/gcloud/emulators/datastore/WEB-INF/appengine-generated/local_db.bin.
You could also send a POST /reset request to the emulator, mentioned here.
I have install the Open Daylight Helium according to the document of wiki of installation. But, when I enable the webUI, it always displays "Unable to login" in the webUI.
How can I solve this problem?
This would be easier to answer if you described what you mean by the web UI. Nonetheless vaerify that you are testing the correctports, if you are then you can disable auth by editing org.opendaylight.aaa.authn.cfg
authEnabled=false
Obviously, we need to install feature of odl-dlux-core. And we can login to ODL's Web GUI successfully.
I had the same problem and I got it working by following the answer on this link:
https://ask.opendaylight.org/question/843/unable-to-login-dlux-web-interface-helium-release/
There it says:
Downloading and extracting the pre-build .zip : distribution-karaf-0.2.0-Helium.zip
./distribution-karaf-0.2.0-Helium/bin/karaf (on linux) to start the karaf container
feature:install odl-restconf odl-l2switch-switch odl-mdsal-apidocs odl-dlux-core
Accessing http://localhost:8181/dlux/index.html where localhost is your local ip
log in with user: admin pw: admin
Perhaps there is a problem with the order you have installed your features. I >got the order from dlux-wiki-page where they said that this is the recommended >way of installing features before starting the dlux feature.
To clean your local karaf container you can start the container using the clean >flag like "./distribution-karaf-0.2.0-Helium/bin/karaf clean" or delete the >"distribution-karaf-0.2.0-Helium/data/" folder.
I'm trying to run a process with elevated privileges - specifically OpenVPN, which requires root privileges to add routes to the system.
Looking around for existing examples around leads me to AuthorizationExecuteWithPrivileges, which seems to be now deprecated.
I tried the new SMJobBless method but I have a few questions regarding its viability for this purpose. As I understand it, I can create a separate privileged tool and communicate with it via sockets to ask the tool to perform privileged commands. However, I can't seem to figure out how I can start the OpenVPN process and capture its standard output in real time doing it this way as the main application would not be starting the process itself.
Another option is to use setuid on the OpenVPN executable. Could I possibly use the helper installed by SMJobBless to set the file permissions and setuid on the executable, then run it normally via NSTask?
Edit:
Lastly is there some way to just run one single command with privileges without having to install anything permanently? Although this new method is more secure, it seems very heavy handed.
I managed to go the SMJobBless method by using a helper and communicating it with XPC (the method shown on Nathan de Vries's Blog). Using this helper I set the permissions on the external process to 04555 (setuid, rx). Then the SMJob is removed as it is no longer required. Essentially emulating an "one-off" privileged job.
Following that I was able to use NSTask to start the process and capture its output in my main application.
Additionally I have a check at the start to see if the permissions are set right on the executable, if not the SMJob helper is re-blessed and permissions set.
If anyone has a cleaner solution, feel free to share. Thanks!
I had the same problem as you, needed it for a OpenVPN Manager App for MacOs X. Your solution is far from optimum because you open the openvpn binary for everyone setting setuid root.
This is a security hole and should be avoided, as it is totally unnecessary when you are using smjobbless helper. This helper runs as root and could do everything you want for you and with administrative privileges, so you can launch openvpn via this helper without setting setuid root on openvpn binary.
Apple designed this process as only your App, the Main App, can communicate with this helper as your Main App and your helper are signed with your developer certificates.
Any malicious App can't use this helper.
When you look at Nathans code you see, that he managed it to send messages to this helper and to get answers from this helper.
In his example there is sth like "Hey there Helper App" and the answer is "Hey there Host App".
So to get sth useful out of this you only have to send commands to the helper app, extract these commands on helper side and launch them with elevated privileges as the helper App runs with elevated privileges.
Look at Nathans code, there is sty like (in smjobblessappcontroller.m):
xpc_object_t message = xpc_dictionary_create(NULL, NULL, 0);
const char* request = "openvpn --config OpenvpnConnection.ovpn";
xpc_dictionary_set_string(message, "request", request);
[self appendLog:[NSString stringWithFormat:#"Sending request: %s", request]];
xpc_connection_send_message_with_reply(connection, message, dispatch_get_main_queue(), ^(xpc_object_t event) {
const char* response = xpc_dictionary_get_string(event, "reply");
[self appendLog:[NSString stringWithFormat:#"Received response: %s.", response]];
});
With this you send the openvpn command to your helper App. You only have to extract this command on helper side to launch the process with elevated privileges.
Look at smjobblesshelper.c and do sth like (in __XPC_Peer_Event_Handler else branch):
const char *response = xpc_dictionary_get_string(event, "request");
In string response you have your openvpn command, now simple launch it:
system(response);
Thats all, this goes with elevated privileges. Now you can use this in your App perhaps in an IBAction push button in your main app, to start openvpn connections as you want every time a user clicks this button.
I am running a rewrite map with an external rewrite program (prg) in apache2 that may produce an error and die.
When the rewrite map is not running any more the system obviously doesn't function properly.
So I wanted to start a simple wrapper shell script that itself executes map program (which is written in php) and restarts it if it dies:
#!/bin/bash
until /usr/bin/php /somepath/mymap.php; do
echo "map died but i will restart it right away!"
done
If I try that in the shell by hand, it works fine, however it does not work when started by the webserver.
...and then communicates with the rewriting engine via its stdin and
stdout file-handles. For each map-function lookup it will receive the
key to lookup as a newline-terminated string on stdin. It then has to
give back the looked-up value as a newline-terminated string on stdout
or the four-character string ``NULL'' if it fails...
The reason seems pretty clear to me. The first script takes stdin but doesn't redirect it to the sub script.
I guess I somehow need to define a descriptor using exec and redirect stdin/stdout of the scripts properly. But how do I do that?
It's a common problem that some script works executed "by hand" and do not work when executed indirectly (via cron or from apache).
Usually the root cause is one of:
your script needs some extra environment varaible (PATH, LD_LIBRARY_PATH, etc.)
your script requires terminal
First thing to do is to grab some debug info, so add to your script:
env > /tmp/$0.env # get environment
and get stderr:
... /usr/bin/php /somepath/mymap.php 2>/tmp/$0.stderr ...
This may lead you to the solution.
If your script requires terminal and you cannot fix it you can run your script via gnu screen.
Good luck.
Michał Šrajer has given one very common cause of trouble (environment). You should certainly be sure that the environment is sufficiently well set up, because Apache sets its own environment rigorously and does not pass on any inherited junk values; it only passes what it is configured to pass (SetEnv and PassEnv directives, IIRC).
Another problem is that you think your mapping process will fail; that's worrying. Further, it is symptomatic of yet another problem, which I think is the main one.
The first time the map process is run, it will read the request from the web server, but if the mapping fails, you rerun it - but the web server is still waiting for the output from the original request, and the map process is waiting for the input, so there's an impasse.
Note that a child process automatically inherits the standard input and standard output of its parent unless you do something to change it.
If you think things might fail, you'll need to capture the standard input so that when you rerun the program, you can resupply the input (though why it would work on the second time when it failed on the first is a separate mystery).
Maybe:
if tee /tmp/xx.$$ | /usr/bin/php /somepath/mymap.php
then : OK
else
until /usr/bin/php /somepath/mymap.php < /tmp/xx.$$
do echo "map died but I will restart it right away!"
done
fi
rm -f /tmp/xx.$$
Unresolved issues include:
You should add traps to ensure that the temporary file is removed;
You should probably not use /tmp as the directory;
The messages probably do not get sent to the web server and from thence to the client browser until the overall script terminates, so the echoed messages simply mess up the start of the response;
There is no limit on the number of failures;
There is no logging of the failures;
There is no attempt to fix the problem that caused the failure;
And there are probably others I've not thought of yet.
until is not a valid keyword, you probably have it aliased and aliases do not work on scripts. my mistake, it seems it is.
regardless, this is what you want to do:
while true; do
/usr/bin/php /somepath/mymap.php
done
if this also fails then yes, either your program expects a terminal or you have something missing in your env.
My Kohana app runs perfectly on my local machine.
When I deployed my app to a server (and adjust the config files appropriately), I can no longer log into the app.
I've traced through the app login routine on both my local version and the server version and they both agree with each other all the way through until you get to the auth.php controller logged_in() routine where suddenly, at line 140 - the is_object($this->user) test - the $user object no longer exists!?!?!?
The login() function call that calls the logged_in() function successfully passes the following test, which causes a redirect to the logged_in() function.
if(Auth::instance()->login($user, $post['password']))
Yes, the password and hash, etc all work perfectly.
Here is the offending code:
public function logged_in()
{
if ( ! is_object($this->user))
{
// No user is currently logged in
url::redirect('auth/login');
}
etc...
}
As the code is the same between my local installation and the server, I reckon it must be some server setting that is messing with me.
FYI: All the rest of the code works because I have a temporary backdoor available that allows me to use the application (view pages of tables, etc) without being logged in.
Any ideas?
I solved the problem (DUH!).
The answer was that the cookie.php config file had $config['domain'] = 'localhost'. Setting this to the actual domain that the app is installed in magically made my life happy again!
Thanks everyone for your help and interest.