New answers tagged sudo
Add /usr/local/lib to /etc/ld.so.conf and run ldconfig, then you'll have this path added as a default path for libraries.
Allowing LD_LIBRARY_PATH for suid binaries like sudo is a security problem, thus LD_LIBRARY_PATH gets stripped out of the environment. sudo by default doesn't passthrough LD_LIBRARY_PATH to its children either for the same security concerns: carefully crafted libraries would allow you to bypass the sudo argument restrictions to execute whatever you want. If ...
I hade the same problem, I checked /var/log/auth.log and syslog for errors. Turns out that my LDAP server could not be reached and it slowed down everything. I did not use LDAP based auth anymore, so I removed all "ldap" references from /etc/nsswitch.conf Since then everything works like a charm again.
Sudosh may be a better solution. It logs sessions as needed and gives you "VCR" capabilities allowing you to replay sessions, its also available in most major distribution package repositories.
After some studying this problem I have found 3rd variant of solving this problem. By editing sudoers we can give user permission to run sudoedit. It's secure way to modify root-only files, without possibility of hack. So answer is hosteditor ALL=(root) sudoedit /etc/hosts
Since version 2.0.0 snoopy is able to log arbitrary environmental variable. However, recent contribution pointed out that logging owner of tty is fairly effective and elegant answer to the question of "Who executed that command, as root?". Disclosure: I am snoopy maintainer.
Using sudo makes it harder for a malicious user to gain access to a system. When there is an unlocked root account, a malicious user knows the username of the account she wants to crack before she starts. When the root account is locked, the user has to determine the username and the password to break into a system.
Any command can be run from vi including a shell so allowing a user to run vi through sudo isn't secure. A safer option would be to set permissions as the previous answer suggests. If you can't do that, configure sudo to allow copying to the file: Cmnd_Alias CP_ETC_HOSTS = /bin/cp -v ./hosts /etc/hosts They can edit a copy of the file and copy their ...
Don't use SUDO for this. Instead, add hosteditor into a group, and delegate write access to that group, using POSIX File ACLs. Look up http://linux.die.net/man/1/setfacl for a command for managing the Access Control Lists, and http://linux.die.net/man/5/acl for the actual write-up on ACLs under Linux. This assumes, of course, that you are using a filesystem ...
SOLVED: one of the admins had installed Spiceworks on the LAN, with access to this user account, and Spiceworks was trying to run these alerted commands to accomplish its monitoring tasks. That's a big relief--apparently no malicious traffic on this one anyway. Here now for posterity.
Capistrano is not implemented to support the use case you describe. You can try setting the git variable to include sudo (set :git, 'sudo git'), however you will then likely run into the issue of your forwarded authentication key not being available to the sudo'ed git command. Perhaps a more fruitful strategy involves adding your user to the group of the ...
Top 50 recent answers are included