How to get root's environment with sudo?
When i work as a plain user sometimes i need to call some programms with superuser rights (e.g. installpkg). I use sudo for it. A lot of this programms are located in /sbin, /usr/sbin, etc. This directories is included to PATH environment variable in root's environment and isn't included in plain user's environment. But when i use sudo PATH is the same as this one in plain user's environment. I've set "Defaults env_reset" in sudoers. I've also tried to use env_keep option. The problem doesn't disappear. I've not found another settings in man sudo, man visudo and man sudoers that could help me to solve this problem. Is it possible to have the same PATH (or another elements of environment) as in root's environment when i use sudo?
|
I'm not sure precisely how sudo works, because I don't use it; however, you can use 'su' instead. su stands for 'substitute user' if I recall correctly, and basically turns you into 'root' or whatever user you 'su' as.
You can either do just plain: # su and enter root password to get root permissions, or you can do: # su - with the dash after, to get a root login shell (which will have the root path and everything else root-esque). Is this what you are after? |
Easiest way to accomplish that is to add /usr/sbin and /sbin to your user's PATH. You can drop a "local.sh" or some such in /etc/profile.d/ to check the value of $USER and append to PATH accordingly.
Alternatively, you might find that invoking "sudo -i" is enough for you, as that gets you a login shell. |
Is it possible to customize su for it don't require password?
|
Quote:
Sasha |
Quote:
|
Please tell me you didn't go there...
You ask if su(1) can be configured to not require a password, and then you tell me that adding /usr/sbin and /sbin to a user's PATH "seems like not quite safe" -- what??? Yes, that makes *PERFECT* sense - because a user can't just use the full path to the executable... I guess I'm done with this discussion. |
Quote:
|
Let me start with saying that I am not a fan of sudo, as it has been used by some distributions in a way it was not designed to be used - in *my* opinion.
But, sudo can be useful in some occasions, like shell scripts that need to execute commands normally only allowed by root. And for these very specific cases, you can use very specific configurations in your sudoers file, so that you do not need to type a password. For instance, I have a script that connects over a VPN to a remote server and the user needs to change the routing table after connecting. The specific "route add ..." command - with the IP address, netmask, etc. - is in the sudoers file so that a normal user can *only* add that specific route. The example from the O.P. of using installpkg is (again, in *my* opinion) not a case for sudo, as it is too generic. If you put installpkg in the sudoers files, you put a security hole in your system. Then that user (or maybe all users, depending on how you configured it) can install any package without bothering about security. Installpkg should be run as root, using su or logging in directly as root, and only after entering its password. <edit> Disclaimer: Of course, it is *your* system, and you can make it as insecure as *you* like. </edit> |
sudo su -
Simple as that. |
Quote:
|
Quote:
For many small systems, the convenience of working as root is useful. Yes, obviously the people given "su" in sudoers can subvert the intention of controlling the root password while allowing them this logged access. So, sure. you've "removed all security". If you have an environment where that is a problem, obviously you don't do that. In this case, he apparently already HAS "su" so apparently that bridge is far behind. But, please: feel free to get all worked up about this if you must. |
Quote:
Like I said a few posts back: "It is *your* system". Linux is all about freedom, each administrator has the choice to configure his / her system as he / she sees fit. There are "best practices" though. |
Quote:
Eric |
Quote:
|
All times are GMT -5. The time now is 07:48 PM. |