New answers tagged sudo
The setuid stanza should not be in script block, it's global. This is probably the reason your job fails for. Note that using setuid will make all job phases run as the user specified and there's no way to change it. If you want to run only a daemon as a different user, avoid sudo and go with start-stop-daemon instead. This is especially important with ...
Using the directions to add a centos 7 box to my 2012r2 domain located Here, I was able to add to my domain. Adding a AD group to sudoers required me to format the group as %GroupName@DOMAIN ALL=(ALL) ALL and it worked.
Sudo is by far the best solution for this, and if I recall from my days working in their support department, the documentation might actually call for that when you are using the legacy unix listener. You could probably hack around it by changing the service account it uses to root, but that is a bit ugly, and running network listeners as root is ...
I found that this works well for this [ $(cat /etc/$PPID/loginuid) -eq 0 ] && [ "$USER" == "root" ]
The host list feature in sudo checks/matches the host names, IP addresses, network numbers, netgroups of the host on which sudo is executed, not those of a remote host. The idea is that a single universal sudoers file can be distributed to a large numbers of servers/workstations and certain privileges are only granted to users on a subset of systems. ...
The only problem would be you can proxy a local port under the first 1024 as root vs your non privileged user. In some cases this is desired issues-setting-up-ssh-tunnel-for-port-80
No, it isn't. chown -R will dereference symbolic links by default. That means if you have a symbolic link to, say, /etc/shadow in your directory, this command will change the owner of /etc/shadow to www-data. It can be made safer with chown -hR, but recursive chowning may have other risks of which I'm unaware.
When sudo invoked, it asks for the password of the user who started it - to ensure the person at the terminal is really the same "joe" who's listed in /etc/sudoers. You must consider this behavior in your program.
To use sudo, you can do sudo iptables-save | sudo tee /etc/sysconfig/iptables The shell don't have the right to write in /etc/sysconfig/iptables, as it is run in your user.
As per Mark's comment, the .k5login file must satisfy the following requirements: The .k5login file must contain one principal per line, be owned by user, and not be writable by group or other (but must be readable by anyone). as per the comments found in the Kerberos source code. In this instance, the .k5login file was not readable by anybody but the ...
Top 50 recent answers are included