Can one get a proper root environment with sudo?
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory. -- Chris Green
On 16 August 2010 17:34, Chris G <cl@isbd.net> wrote:
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory.
sudo su -
On 16/08/10 18:45, Tim Green wrote:
On 16 August 2010 17:34, Chris G<cl@isbd.net> wrote:
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory.
sudo su -
To be fair if you are doing that frequently you may as well set a root password and be done with it :)
On Mon, Aug 16, 2010 at 08:11:47PM +0100, Wayne Stallwood wrote:
On 16/08/10 18:45, Tim Green wrote:
On 16 August 2010 17:34, Chris G<cl@isbd.net> wrote:
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory.
sudo su -
To be fair if you are doing that frequently you may as well set a root password and be done with it :)
I have a root password on my desktop system but on the others it just seems easier to stay with the default Ubuntu setup. I don't have to invent more passords either! :-) -- Chris Green
On Mon, Aug 16, 2010 at 06:45:55PM +0100, Tim Green wrote:
On 16 August 2010 17:34, Chris G <cl@isbd.net> wrote:
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory.
sudo su -
Aha, brilliant, thanks. It's obvious when you think about it but I'd somehow got hooked on 'sudo -s'. -- Chris Green
On 16 Aug 20:43, Chris G wrote:
On Mon, Aug 16, 2010 at 06:45:55PM +0100, Tim Green wrote:
On 16 August 2010 17:34, Chris G <cl@isbd.net> wrote:
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory.
sudo su -
Aha, brilliant, thanks. It's obvious when you think about it but I'd somehow got hooked on 'sudo -s'.
Except that's the wrong answer. *sigh*. sudo -i Which fires off a login shell as the user you're sudoing to, so, for instance, I tend to use: sudo -u <someotheruser> -i At which point I'm running their login shell, I am them, and I have the environment setup as them. Works, is much cleaner than wrapping a privelege escalation tool in a privilege escalation tool, and gives the correct results. Simples. -- Brett Parker
On 17 August 2010 10:00, Brett Parker <iDunno@sommitrealweird.co.uk> wrote:
On 16 Aug 20:43, Chris G wrote:
On Mon, Aug 16, 2010 at 06:45:55PM +0100, Tim Green wrote:
On 16 August 2010 17:34, Chris G <cl@isbd.net> wrote:
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory.
sudo -i
Which fires off a login shell as the user you're sudoing to, so, for instance, I tend to use: sudo -u <someotheruser> -i
At which point I'm running their login shell, I am them, and I have the environment setup as them. Works, is much cleaner than wrapping a privelege escalation tool in a privilege escalation tool, and gives the correct results.
Thanks, Brett. The answer is, of course, in "man sudo" amongst the 18 or so other options. Tim.
On 17-Aug-10 09:39:48, Tim Green wrote:
On 17 August 2010 10:00, Brett Parker <iDunno@sommitrealweird.co.uk> wrote:
On 16 Aug 20:43, Chris G wrote:
On Mon, Aug 16, 2010 at 06:45:55PM +0100, Tim Green wrote:
On 16 August 2010 17:34, Chris G <cl@isbd.net> wrote:
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. _It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory.
sudo -i
Which fires off a login shell as the user you're sudoing to, so, for instance, I tend to use: _ _sudo -u <someotheruser> -i
At which point I'm running their login shell, I am them, and I have the environment setup as them. Works, is much cleaner than wrapping a privelege escalation tool in a privilege escalation tool, and gives the correct results.
Thanks, Brett. The answer is, of course, in "man sudo" amongst the 18 or so other options. Tim.
I've been quietly watching this one, with slight puzzlement! If I'm logged in as (say) "ted", and in that login I do su - and at the prompt enter the root password, then I'm fully logged in as "root", environment and all. Ctrl+D to log out, of course, and back to being "ted". Similar of course to switch to any other user, e.g. "guest": su - guest So what's all the fuss about? Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@manchester.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 17-Aug-10 Time: 10:55:36 ------------------------------ XFMail ------------------------------
On Tue, Aug 17, 2010 at 10:55:39AM +0100, Ted Harding wrote:
On 17-Aug-10 09:39:48, Tim Green wrote:
On 17 August 2010 10:00, Brett Parker <iDunno@sommitrealweird.co.uk> wrote:
On 16 Aug 20:43, Chris G wrote:
On Mon, Aug 16, 2010 at 06:45:55PM +0100, Tim Green wrote:
On 16 August 2010 17:34, Chris G <cl@isbd.net> wrote:
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. _It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory.
sudo -i
Which fires off a login shell as the user you're sudoing to, so, for instance, I tend to use: _ _sudo -u <someotheruser> -i
At which point I'm running their login shell, I am them, and I have the environment setup as them. Works, is much cleaner than wrapping a privelege escalation tool in a privilege escalation tool, and gives the correct results.
Thanks, Brett. The answer is, of course, in "man sudo" amongst the 18 or so other options. Tim.
I've been quietly watching this one, with slight puzzlement! If I'm logged in as (say) "ted", and in that login I do
su -
and at the prompt enter the root password, then I'm fully logged in as "root", environment and all. Ctrl+D to log out, of course, and back to being "ted".
Similar of course to switch to any other user, e.g. "guest":
su - guest
So what's all the fuss about?
That only works if you *have* a root password set up. Many distributions don't and expect all 'root' operations to be done by a user with sudo/root privileges rather than actually as root. You can argue all day as to which is the best approach. Using sudo and not have a real root has the advantage that you don't have to remember another password and there is a trace of who broke things (I never do of course!). On the other hand having a real root gives the extra security of needing to know the root password as well as the user's password. (Assuming root isn't allowed to ssh and you're worried about attacks that way) -- Chris Green
Chris G wrote:
(Assuming root isn't allowed to ssh and you're worried about attacks that way)
We overcome that in 2 ways: 1) we don't allow root to SSH 2) We only permit key-pair SSH login Cheers, Laurie. -- --------------------------------------------------------------------- Laurie Brown laurie@brownowl.com ---------------------------------------------------------------------
Laurie Brown wrote:
Chris G wrote:
(Assuming root isn't allowed to ssh and you're worried about attacks that way)
We overcome that in 2 ways:
These settings have been debated a few times at the co-op. As a result, we have different servers with different settings. Workers have identified problems with both of these ways:
1) we don't allow root to SSH
Now I agree with that, but I think tramp (for Emacs) is the only pseudo-filesystem that allows elegant editing of root files through sudo with its "multi-hop methods". So, there is pressure from Vi users to allow root sftp at least on loopback.
2) We only permit key-pair SSH login
I think the weaknesses in this one are: a) ssh clients on mobile devices, some of which need the key to be generated on one host and then converted and sent to the mobile device. (putty on s60, for example) b) inability of the server to detect if the key has a passphrase. If it doesn't, then isn't it no better in theory than a password login? Has anyone smarter than me got solutions for any of those? Thanks, -- MJ Ray (slef) Webmaster and developer for hire at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
MJ Ray wrote: [SNIP]
2) We only permit key-pair SSH login
I think the weaknesses in this one are:
a) ssh clients on mobile devices, some of which need the key to be generated on one host and then converted and sent to the mobile device. (putty on s60, for example)
Agreed, but that's a price worth paying, IMO. I use Putty with key-pair from my Nokia E90 probably every day. I don't recall having to convert it, and copying it up was a doddle (using Nokia software on a 'Doze machine, admittedly).
b) inability of the server to detect if the key has a passphrase. If it doesn't, then isn't it no better in theory than a password login?
Agreed (although stealing the key might be a challenge), but only an idiot would bother to config key-pair and then fail to go the tiny bit extra and not have a passphrase!
Has anyone smarter than me got solutions for any of those?
Nope! Cheers, Laurie. -- --------------------------------------------------------------------- Laurie Brown laurie@brownowl.com ---------------------------------------------------------------------
On 17 Aug 12:41, Laurie Brown wrote:
MJ Ray wrote:
[SNIP]
2) We only permit key-pair SSH login
I think the weaknesses in this one are:
a) ssh clients on mobile devices, some of which need the key to be generated on one host and then converted and sent to the mobile device. (putty on s60, for example)
Agreed, but that's a price worth paying, IMO. I use Putty with key-pair from my Nokia E90 probably every day. I don't recall having to convert it, and copying it up was a doddle (using Nokia software on a 'Doze machine, admittedly).
The N900 I use is even easier, I just generated the key on it. But then, it really is a tablet PC that happens to also work as a phone... (it's a lovely ARM based device).
b) inability of the server to detect if the key has a passphrase. If it doesn't, then isn't it no better in theory than a password login?
Agreed (although stealing the key might be a challenge), but only an idiot would bother to config key-pair and then fail to go the tiny bit extra and not have a passphrase!
If it's on a mobile device, stealing it ain't that difficult... Of course, you've got a way to remove a particular public key from authorized_keys, right? ;)
Has anyone smarter than me got solutions for any of those?
Nope!
Don't do remote editing of root files? If they're config files, store them in (some form of) version control, and get that to roll out the changes for you instead... -- Brett Parker
On 17 Aug 10:55, Ted Harding wrote:
I've been quietly watching this one, with slight puzzlement! If I'm logged in as (say) "ted", and in that login I do
su -
and at the prompt enter the root password, then I'm fully logged in as "root", environment and all. Ctrl+D to log out, of course, and back to being "ted".
Similar of course to switch to any other user, e.g. "guest":
su - guest
So what's all the fuss about?
OK - *unless* you've spent time messing with the pam config for su, that requires you to have the password for the user that you're becoming, on multiuser systems you haven't neccessarily got that password, and that's where sudo comes in. sudo *can* be configured to ask for the target users password, or for the current users password. Also, it tends to cache that it's authenticated and the user is allowed to do things, and so after the first sudo, until the timeout, the user can just run sudo again without having to type a password at all. My main complaint was the mix of sudo *and* su, which is a horrible hack that is not required as sudo has a lovely -i option. Hope that clears it up a bit... (in other news, it *is* fairly simple to make it so that su will happily let anyone in the root group su without a password, infact, on a debian install, if you look at /etc/pam.d/su you'll see the (by default disabled) lines to do that. There's also many other things that you can do with PAM... but as always, when it comes to auth, be very very careful!) Cheers, -- Brett Parker
On Tue, Aug 17, 2010 at 10:00:42AM +0100, Brett Parker wrote:
On 16 Aug 20:43, Chris G wrote:
On Mon, Aug 16, 2010 at 06:45:55PM +0100, Tim Green wrote:
On 16 August 2010 17:34, Chris G <cl@isbd.net> wrote:
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory.
sudo su -
Aha, brilliant, thanks. It's obvious when you think about it but I'd somehow got hooked on 'sudo -s'.
Except that's the wrong answer. *sigh*.
sudo -i
Which fires off a login shell as the user you're sudoing to, so, for instance, I tend to use: sudo -u <someotheruser> -i
At which point I'm running their login shell, I am them, and I have the environment setup as them. Works, is much cleaner than wrapping a privelege escalation tool in a privilege escalation tool, and gives the correct results.
OK, I suppose it is cleaner, takes longer to type though! :-) -- Chris Green
On 16/08/10 17:34, Chris G wrote:
I tend to use 'sudo -s' when I want to do a series of things as root, it generally works fine but I have just noticed a minor issue. It doesn't set a proper root environment so that you still have the environment of the user who sudo'ed to root - in particular there is the PATH which may have all sorts of oddities on it and HOME is still set to your home directory.
I use sudo bash which is goodenuff for me. nev
participants (8)
-
Brett Parker -
Chris G -
Laurie Brown -
MJ Ray -
nev young -
Ted.Harding＠manchester.ac.uk -
Tim Green -
Wayne Stallwood