Any reasons anymore to NOT change the default root shell to one that's not built-in?

rwv37

rwv37

I know that for a long time, the standard advice for the default root shell was "don't change it" (which I learned many years ago when I got myself into a mess after having changed it ?). Is that still the case? I seem to remember that the issue was that if you changed it to, say, /usr/local/bin/bash, and for some reason your /usr wasn't mounting or whatever, you would be unable to start up a root shell in order to fix it. But at least now, the single user boot prompts for a choice of shell, so it seems to me like that isn't really an applicable reason anymore (at least, assuming physical access to the machine, which I have).

Am I right about that? And in any case, are there any other reasons why it's a bad idea to change it? To be clear, I am the only person using the machine, so anything like "upsetting other wheel members" is not an issue.

Thanks in advance.
 
Another reason you could run into: eventually, your libc might get updated and/or ABI-incompatible (if you do a major upgrade). Then you won't be able to run i.e. bash. You'd have to go to single user mode to fix that, unless you have a toor user for example.

If you use a statically linked binary of said shell, you might be able to work around the issue, I believe, but the usual bash installation is dynamically linked, AFAIK. Still, the library issue could also relate to other libraries beyond libc. So, the less dependencies your root shell has got, it's probably for the better - and that simply (mostly) applies to shells which are in base.

EDIT: and yes, you're right about /usr; if that's not mounted for whatever reason, your SOL.
 
cmoerz said:
Another reason you could run into: eventually, your libc might get updated and/or ABI-incompatible (if you do a major upgrade). Then you won't be able to run i.e. bash. You'd have to go to single user mode to fix that, unless you have a toor user for example.

If you use a statically linked binary of said shell, you might be able to work around the issue, I believe, but the usual bash installation is dynamically linked, AFAIK. Still, the library issue could also relate to other libraries beyond libc. So, the less dependencies your root shell has got, it's probably for the better - and that simply (mostly) applies to shells which are in base.

EDIT: and yes, you're right about /usr; if that's not mounted for whatever reason, your SOL.
Click to expand...

Thanks, but to be clear (unless I'm misunderstanding what you're saying): I'm not terribly concerned about problems if they could be solved by booting to single user mode and selecting "/bin/sh" or "/bin/csh".
 
Ah, fair point. I didn't pick up on that on my first read. Apologies.

If you do have console access, you could always fallback to other options, you're right. Unless you're working a remote system without a KVM or other console, you generally should be fine. So the library dependencies aren't much of a worse situation than ABI or other ill effects you could probably encounter.

Even if you were to uninstall i.e. bash by accident, you could still go single mode.

If taking the system to single mode is the accepted workaround, I can't really think of any other reason either, to be honest.
 
rwv37 said:
I'm not terribly concerned about problems if they could be solved by booting to single user mode and selecting "/bin/sh" or "/bin/csh".
Click to expand...
Then it's not a problem (but was not a problem ever as reasons for not doing it are still the same).
I'd add an option to be able to recover system from rescue mode booted from external media. If you are confident there then it's ok.
 
rwv37 said:
Thanks, but to be clear (unless I'm misunderstanding what you're saying): I'm not terribly concerned about problems if they could be solved by booting to single user mode and selecting "/bin/sh" or "/bin/csh".
Click to expand...
And, if you have an account like "toor" set up with a shell that's pretty much guaranteed to work, you have belt and suspenders: You can use the toor account in multi-user mode, and you can go to single user.

Personally, I use bash for root. I just don't see the (tiny) risk of having to log in as something else or reboot as significant to justify working with a shell I don't find comfortable. YMMV.
 
ralphbsz said:
if you have an account like "toor" set up with a shell that's pretty much guaranteed to work, you have belt and suspenders
Click to expand...
I agree. What I do differently is I set user of different name to uid 0 which has /bin/sh as shell. It's sort of a security measure as this user can ssh with password. But otherwise it's user I never use for anything.

Caveat to this solution: I come from shared int. environment. Many companies where contract allows it like to have their own *root account. One way is to push users with uid 0 and name acmeroot, or rootabc... (so similar to toor).
Problem is when inexperienced admin from given account tries to remove files of its user this way: find /usr -name acmeroot -exec rm {} \;. I did have to do few restores due to this.

*There are way too many different ways to set this, many are in place. This is however one of the ways too.
 
Thanks everybody. A little further question that your answers have got me thinking about: Any particular reason not to set toor's default shell to /rescue/sh instead of /bin/sh?

To be clear, I never do anything with toor; I just have it set up to be available for logging in, in case of emergency. Given that, it seems like maybe /rescue might be a little safer, since it depends on less? But I don't really know enough to say for sure.

I (think I) know optimally you would want to use it off of a live CD or something rather than off of the machine itself, but if the situation is more "Oh crap, I shouldn't have hit return" and less "I have reason to believe my files on disk may have been corrupted", it seems like booting from a live CD might be unnecessary effort?
 
You can set it to whatever you want. You don't necessarily need that shell to be included in /etc/shells either, ssh access would work in default configuration. Idea is if you can't execute /bin/sh there's very good chance you have deeper problems than what is your shell set to. Most likely you'll be doing some sort of recovery anyway.
 
rwv37 said:
Thanks everybody. A little further question that your answers have got me thinking about: Any particular reason not to set toor's default shell to /rescue/sh instead of /bin/sh?

...<snip>
Click to expand...
Not that I know of. Just don't remove the file: /bin/sh because many shell scripts start with the line: #!/bin/sh as a "shebang" line to select the correct shell interpreter program, and many of them will not run correctly if they're unable to load the correct interpreter.
 
Some web hosts (AWS Lightsail for instance) don't give you full console login access, just browser-based SSH. I was upgrading a box a few weeks ago and got into a weird state halfway through the upgrade where bash was broken. Luckily I didn't change the root user's shell otherwise I would have been in bad shape.

As long as you have true console access or physical access to the machine you might be OK, but I'm just going to stick to the practice of leaving the root shell alone. I feel like it's a better habit. YMMV.

Also, by not making root's shell "nice and fancy" it helps limit the amount of time I stay in there.
 
for years now, i set my users' shell to /usr/local/bin/fish, and my root shell to tcsh — on servers. On my development systems, i usually set root's shell to fish, too, for comfort.

I've never hosed a system so badly that that was the problem. And i hack on PkgBase.
 
If you know how to deal with the inevitable issues you're going to run into, then change root's shell. The standard advice of not changing root's shell is primarily aimed at new users. Users that simply don't know how to cope with a broken system where they can't login anymore. And it's really easy to get in a situation like that after a major version upgrade.
 
ralphbsz said:
Personally, I use bash for root. I just don't see the (tiny) risk of having to log in as something else or reboot as significant to justify working with a shell I don't find comfortable. YMMV.
Click to expand...

I use csh because I don't like it. I'm not tempted to use one-liners, and I think being a little uncomfortable in a root shell is a good thing.

bash is only 5 key-stokes away if I need it.
 
bob2112 said:
I use csh because I don't like it.
Click to expand...
wow I never read that type of motivation to avoid messing with the root account, I suppose it's enough to stay away from it.
In any case it's a good one you made me laugh, in the good way (this is not sarcastic).
 
The default shell for root used to be csh(1) (since the very early versions of BSD). It got changed not too long ago, root's default shell is now sh(1).
 
What ever OS I use I often tend to tweak the .*rc to make it more "friendly for me" even for the root account.
I must admit that I almost never change its default shell unless it's a VM, if it's a jail a friendly .*shell*rc AND an inputrc is enough for me most of the time.
But may be I will try some changes why not.
 
You must log in or register to reply here.
Back
Top