# Default shell for root and users is different



## bugzeo (Jul 29, 2021)

Today found out, after a reboot, that root users has shell history (up arrow brings previous commands). However new added users don't have that convenience. Then found out that "root" uses "/bin/csh", while users use "/bin/sh", and they are not the same (not a symlink or same hash).

So I wonder if I could change my user's shell to csh and don't break my system, and what's the reason for using different shells for each.


----------



## eternal_noob (Jul 29, 2021)

See 3.9.1. Changing the Shell
But whatever you do, never ever change roots shell.


----------



## bsduck (Jul 29, 2021)

bugzeo said:


> So I wonder if I could change my user's shell to csh and don't break my system


Of course. Many alternatives are also available as ports: in https://www.freshports.org/shells

That being said, I use regular /bin/sh and I do have command history with the up arrow. No idea why it doesn't work for you.



eternal_noob said:


> But whatever you do, never ever change roots shell.


You can change it to /bin/sh, but don't use a shell from ports for root, indeed.


----------



## bugzeo (Jul 30, 2021)

Moved my user from "/bin/sh" to "/bin/csh" and now I have all the history after reboot. No idea why sh doesn't have it, any way to check?


----------



## gpw928 (Jul 30, 2021)

eternal_noob said:


> See 3.9.1. Changing the Shell
> But whatever you do, never ever change roots shell.


I have been changing root's shell (to a statically linked /bin/ksh) for the better part of 25 years, and never had an issue.
I do that because, when the chips are down, and I'm sweating blood, as root, in single user mode, I don't want to be using an unfamiliar shell!
In fact, if I ever login as root, for any reason, I don't want to be faced with a shell that behaves in ways that are "abnormal" to me, and thus likely to cause me to make errors.
The only issues you have to be aware of is to make sure that root's shell:

has no dynamic dependencies (i.e. shared libraries) outside the root; and
is properly maintained (i.e. kept at current patch level).

​


----------



## eternal_noob (Jul 30, 2021)

gpw928 said:


> The only issues you have to be aware of is to make sure that root's shell:
> 
> has no dynamic dependencies (i.e. shared libraries) outside the root; and
> is properly maintained (i.e. kept at current patch level).


Yes, you're right. If you know what you do you can even change root's shell. But i believe it's better to tell people "Don't do it".


----------



## SirDice (Jul 30, 2021)

bugzeo said:


> Then found out that "root" uses "/bin/csh", while users use "/bin/sh", and they are not the same (not a symlink or same hash).


They are entirely different shells, why would they be "the same"? One is a C Shell and the other is a Bourne compatible Almquist Shell. There are many different types of shell you can use. 



bugzeo said:


> So I wonder if I could change my user's shell to csh and don't break my system


Users can change their shell to anything they like. I personally like tcsh(1). Others like a Korn shell, or Bash, or Zsh. Only two types of shell come with the base OS; tcsh(1) and sh(1). And there are many other shells you can install via ports/packages. There's even an entire category for them: https://www.freshports.org/shells/



bugzeo said:


> No idea why sh doesn't have it, any way to check?


Because FreeBSD's sh(1) only has a rudimentary history. The history is not persistent, it's not saved between sessions.

The default shell that's shown with adduser(8) can be changed too. Just run `adduser -C` and change it.


----------



## byrnejb (Jul 30, 2021)

eternal_noob said:


> But whatever you do, never ever change roots shell.


Just to make absolutely clear the implications of that statement:  If the shell for the root user cannot run during boot up then the host will fail to start and you will be in a recovery situation. 

Changing the_ root_ shell introduces the possibility that the one selected will not be available when the system next reboots, either by removal or change of location following a `pkg upgrade`, or other misadventure.

If you want root to have a different shell when working on a host then either configure the _toor_ user with that shell and use _too_r; or switch to your preferred shell after logging on as _root_.


----------



## SirDice (Jul 30, 2021)

byrnejb said:


> If the shell for the root user cannot run during boot up then the host will fail to start and you will be in a recovery situation.


It doesn't have anything to do with this. All boot scripts are using sh(1) (all scripts as a matter of fact). Root's configured shell has nothing to do with this.



byrnejb said:


> Changing the_ root_ shell introduces the possibility that the one selected will not be available when the system next reboots, either by removal or change of location following a `pkg upgrade`, or other misadventure.


Problems typically occur when upgrading to a new major version. In that case libraries like the C standard library might change version and anything installed as a port or package may fail to load or work when they haven't been updated yet (this is why you need to _reinstall_ everything after a major version upgrade). There are a few other cases where this could lead to problems, especially when you're working remotely. To prevent _any_ kind of issue simply leave root's shell set to csh(1).


----------



## olli@ (Jul 30, 2021)

For normal users, you probably want to use a more advanced bourne-compatible shell, like shells/zsh or shells/bash.

As far as root’s shell is concerned – that one doesn’t really matter much, because you never use it anyway. Some people even set root’s shell to `/usr/bin/nologin` for improved security, but it really doesn’t matter much, provided that your root account has a strong password. *Never log in as root!* Instead, log in as normal user, and then do `su -m` which gives you your own login shell (the one of your normal user account, not root’s) with added root privileges. Or use one of the various tools for the ports collection for executing tasks that require root privileges: security/super, security/doas or security/sudo.

Note, when you’re booting into single-user mode, init(8) will ask you for the shell to use, the default being `/bin/sh`. So the shell of the root account is meaningless here, too.

[Edit] PS: The fact that root’s default shell is /bin/csh has purely historic reasons, and it probably won’t change in FreeBSD because of some developers’ irrational feelings attached to BSD’s history. Personally I think that csh / tcsh should be removed from FreeBSD’s base system.


----------



## bugzeo (Jul 30, 2021)

bsduck said:


> That being said, I use regular /bin/sh and I do have command history with the up arrow. No idea why it doesn't work for you.


As long as you don't exit session, of course you have history, but it's on memory. If you exit with Ctrl+D, previous history will not exist. Either that, or your sh is a symlink to another shell that has history.


----------



## Geezer (Jul 31, 2021)

olli@ said:


> *Never log in as root!*



Good advise. Is it actually practical?

Should it be, "_Rarely login as root!_"


----------



## bsduck (Jul 31, 2021)

bugzeo said:


> As long as you don't exit session, of course you have history, but it's on memory. If you exit with Ctrl+D, previous history will not exist. Either that, or your sh is a symlink to another shell that has history.


Yes, that's what I have. I didn't think you meant persistent history. In fact that's a thing I always disable on other shells like bash, I don't like my history to be saved to disk (same with web browsers).


----------



## kpedersen (Jul 31, 2021)

olli@ said:


> [Edit] PS: The fact that root’s default shell is /bin/csh has purely historic reasons, and it probably won’t change in FreeBSD because of some developers’ irrational feelings attached to BSD’s history. Personally I think that csh / tcsh should be removed from FreeBSD’s base system.


Out of interest, do you have a source on hand as to why? I have always wondered this myself.

That said, `csh` is fairly tiny so it certainly doesn't harm things staying around. In some ways it is also a good defense against beginners saying:


> FreeBSD only has */bin/sh*?!?, we should have more than one choice so I want *bash* or *fish* in base!


I would rather `csh` in there than those fat old things (and I say this as an interactive `bash` user).


----------



## bugzeo (Jul 31, 2021)

Changed my user shell to *zsh* finally. Quite feature rich, even you can do a full step-by-step config before getting started. Overwhelming for new users.


----------



## bugzeo (Jul 31, 2021)

bsduck said:


> Yes, that's what I have. I didn't think you meant persistent history. In fact that's a thing I always disable on other shells like bash, I don't like my history to be saved to disk (same with web browsers).


Yes I meant persistent history, sorry didn't explain better. Out of curiosity found out, that certain shells like bash, allow to not save commands to history if you start the command with a space. not all systems have it set by default, but can be changed easily:

```
bash
export HISTCONTROL=ignorespace
echo '1'
 echo '2'
history | tail -n 2
```
You will see that echo 2 will not be saved even on current session, you don't have to even close with CTRL+D. Really helpful didn't know that trick


----------



## gpw928 (Jul 31, 2021)

kpedersen said:


> Out of interest, do you have a source on hand as to why [root’s default shell is /bin/csh]? I have always wondered this myself.


i got my first 4 BSD release on 9-track tape in 1983.  Root's csh goes back to at least then.

There were a half dozen, or so, accounts installed in /etc/passwd on every BSD system that belonged to the core team.

The release tapes were made so that core team members could work on any system.

In the transition from V6 to V7 Unix, the V6 shell (Ken Thompsons' work) was ditched fast, in favour of the V7 Bourne shell, which had a much better design.

The V6 and V7 Bourne shells had no command history or editing.  They were clumsy for interactive use.

Bill Joy had written a few handy things that many Unix users found useful, including csh (vi deserves a mention, as well).

My guess is that it was made the default for everyone, including root, just because the core team preferred it (and especially its interactive features) to the Bell Labs shells of the day.

[The source code for David Korn's shell was available inside Bell Labs by around 1983 or 1984, but not available in any release of Unix until much later.]


----------



## olli@ (Aug 1, 2021)

Geezer said:


> Good advise. Is it actually practical?
> 
> Should it be, "_Rarely login as root!_"


No, I really mean “_never_ log in as root”. And it is definitely practical. I haven’t logged in as root for the past 25 years. There’s no reason to do that, and good reasons not to.


----------



## gpw928 (Aug 2, 2021)

I think that it's pretty well established professional etiquette that logging in as root is a bad thing to do.  In work places with well developed security protocols, its almost always forbidden because it breaks the audit trial by providing an anonymous privileged login.

Having said that, at home, its not beyond me to login as root on my notebook or my zfs server to start xdm -- because I don't start xdm by default, and typing "xdm" is all I do.  I don't feel any guilt there...

Regardless of whether I might occasionally login as root, or not, I choose to furnish a full login environment for root, with my preferred shell, profile, and aliases, all ready to go in an emergency.  The reason is quite simply because the root login is the only one guaranteed to be fully furnished when /usr is not mounted -- and I refuse to struggle with csh (or anything less than my preferred shell) at a time when the integrity of my system is at risk.

I should also say that this approach relates to systems I own personally.  I never did this when working in a team environment, where you would would want to see some pretty broad and strong agreement before making such changes.


----------



## olli@ (Aug 2, 2021)

gpw928 said:


> I think that it's pretty well established professional etiquette that logging in as root is a bad thing to do.  In work places with well developed security protocols, its almost always forbidden because it breaks the audit trial by providing an anonymous privileged login.


In fact, it is usually disabled for security reasons, so you _cannot_ log in as root, even if you wanted to.
 


> Having said that, at home, its not beyond me to login as root on my notebook or my zfs server to start xdm -- because I don't start xdm by default, and typing "xdm" is all I do.  I don't feel any guilt there...


Actually, that’s a perfect example for using one of security/super, security/doas orsecurity/sudo, instead of logging in as root.
 


> Regardless of whether I might occasionally login as root, or not, I choose to furnish a full login environment for root, with my preferred shell, profile, and aliases, all ready to go in an emergency.  The reason is quite simply because the root login is the only one guaranteed to be fully furnished when /usr is not mounted -- and I refuse to struggle with csh (or anything less than my preferred shell) at a time when the integrity of my system is at risk.


When booting into single-user mode, init(8) asks for the shell to run, and /bin/sh is the default. So you don’t have to struggle with csh at all.
 
Personally I have a habit to keep a statically linked binary of shells/zsh in the /rescue directory, for cases where I have to use single-user mode for more than just a few simple commands. But there were only very few occasions when I actually used it, like two or three times in 25 years.
 


> I should also say that this approach relates to systems I own personally.  I never did this when working in a team environment, where you would would want to see some pretty broad and strong agreement before making such changes.


Agreed. Definitely.


----------



## gpw928 (Aug 2, 2021)

olli@ said:


> When booting into single-user mode, init(8) asks for the shell to run, and /bin/sh is the default. So you don’t have to struggle with csh at all.


You have ignored the bit where I said "my preferred shell, profile, and aliases, all ready to go in an emergency".
Sure, I can use /bin/sh, but I choose, and am certainly most comfortable and productive with, a Korn Shell.
That is why I furnish and test these facilities (statically linked ksh, profile, and aliases) every time I build a system.
Logging in as root occasionally to do trivially safe things keeps them tested and working.

You are right that such preparations tend to be rarely used.  But it only takes one major incident...


----------



## gpw928 (Aug 2, 2021)

olli@ said:


> In fact, it is usually disabled for security reasons, so you _cannot_ log in as root, even if you wanted to.


I have never worked in a place where root logins were disabled.
Root passwords were usually kept in a password safe (one place actually had a physical safe), with restricted and audited access.
But if the LDAP servers went down, the root login (which was the only local login) would be your only way in.
And when the LDAP servers were Linux boxes, you can see the Catch 22 we are avoiding...


----------



## rotor (Aug 3, 2021)

Is there a place in the documentation that says whether non /bin/sh shells in the base system, e.g., /bin/tcsh, are statically linked?


----------



## memreflect (Aug 3, 2021)

rotor said:


> Is there a place in the documentation that says whether non /bin/sh shells in the base system, e.g., /bin/tcsh, are statically linked?


I'm not aware of any such documentation, and it would be a false claim anyway.

However, /rescue/ is documented in 3.5 Directory Structure in the FreeBSD Handbook as a directory containing statically linked programs.  See the difference for yourself:

```
$ file /bin/sh /rescue/sh /bin/tcsh /rescue/tcsh
/bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0 (1300139), FreeBSD-style, stripped
/rescue/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 13.0 (1300139), FreeBSD-style, stripped
/bin/tcsh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0 (1300139), FreeBSD-style, stripped
/rescue/tcsh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 13.0 (1300139), FreeBSD-style, stripped
```


----------



## gpw928 (Aug 3, 2021)

rotor said:


> Is there a place in the documentation that says whether non /bin/sh shells in the base system, e.g., /bin/tcsh, are statically linked?


It's also relevant to see where the dynamic dependencies are. i.e.
	
	



```
[ritz.137] $ ldd /bin/sh /bin/csh /bin/tcsh
/bin/sh:
    libedit.so.7 => /lib/libedit.so.7 (0x800849000)
    libc.so.7 => /lib/libc.so.7 (0x800a83000)
    libncursesw.so.8 => /lib/libncursesw.so.8 (0x800e3a000)
/bin/csh:
    libncursesw.so.8 => /lib/libncursesw.so.8 (0x800887000)
    libcrypt.so.5 => /lib/libcrypt.so.5 (0x800ae6000)
    libc.so.7 => /lib/libc.so.7 (0x800d04000)
/bin/tcsh:
    libncursesw.so.8 => /lib/libncursesw.so.8 (0x800887000)
    libcrypt.so.5 => /lib/libcrypt.so.5 (0x800ae6000)
    libc.so.7 => /lib/libc.so.7 (0x800d04000)
```
You can see that there's nothing required outside the root for these three shells which are in /bin.  So they should be good to go when /usr is not mounted.
However, it's possible to argue that a statically linked shell has fewer dependencies, and possibly more likely to be available in extreme circumstances.
From experience, I know that both ksh and bash have options when compiled and linked from the ports tree for either dynamic or static linking -- but the dynamic linked versions have dependencies in /usr.
Finally, all valid shells (those which are allowed to be appear in /etc/passwd) have their path mentioned in /etc/shells.


----------



## SirDice (Aug 3, 2021)

memreflect said:


> However, /rescue/ is documented in 3.5 Directory Structure in the FreeBSD Handbook as a directory containing statically linked programs.


Not only are they statically linked they're more like busybox, almost everything is linked to a single executable. Just look at the inodes; `ls -ali /rescue`


----------



## olli@ (Aug 3, 2021)

gpw928 said:


> You have ignored the bit where I said "my preferred shell, profile, and aliases, all ready to go in an emergency".


You have ignored the bit where I said “init(8) asks for the shell to run”. 
So, if your preferred shell is /bin/ksh, then you enter that. I don’t see a problem here.
 


> You are right that such preparations tend to be rarely used.  But it only takes one major incident...


I had such incidents in the past, both at work and at home. But I don’t think I’ve ever had to spend more than 15 minutes in single-user mode in order to fix things in a way so I was able to boot multi-user again and log in normally.
 
Actually I’m a zsh addict and make heavy use of advanced zsh features, e.g. I’ve written a lot of custom completion functions, dynamic aliases and things like that. When people watch me typing, it often looks like magic to them.  However, I still know the standard /bin/sh well enough to be able to work with it for 15 minutes in an emergency situation. This happens once in several years, so it’s just not worth the effort to build an advanced root environment just for single-user mode; that would be a waste of time, IMHO. As I wrote previously, I have a habit to keep a statically linked binary of zsh in /rescue (my update script does this automatically whenever zsh is updated), but I rarely ever use it.

YMMV, of course.


----------



## olli@ (Aug 3, 2021)

gpw928 said:


> I have never worked in a place where root logins were disabled.
> Root passwords were usually kept in a password safe (one place actually had a physical safe), with restricted and audited access.
> But if the LDAP servers went down, the root login (which was the only local login) would be your only way in.
> And when the LDAP servers were Linux boxes, you can see the Catch 22 we are avoiding...


Maybe you haven’t worked at places that were extremely concerned about security. I always give the advice to disable root logins completely. They are already disabled by default via ssh, but it’s also advisable to disable local root logins.
 
If things break in a way that you cannot log in normally anymore – including LDAP servers going down –, you can still boot into single-user mode. No root login required. (At least not with FreeBSD, but I guess Linux is similar enough in this regard). Of course, you can (and should!) configure your machines so that the root password is required for entering single-user mode, and this password should be kept in a safe place, as you described above. And also, the machines should be physically secured, to prevent someone from booting via USB stick or similar.


----------



## Alain De Vos (Aug 3, 2021)

It is lesser known that you can use any shell as root shell without any problem.
Just make sure you have a staticly linked toor shell for the toor recovery user, e.g. mksh or oksh.


----------



## gpw928 (Aug 4, 2021)

olli@ said:


> You have ignored the bit where I said “init(8) asks for the shell to run”.
> So, if your preferred shell is /bin/ksh, then you enter that. I don’t see a problem here.


By default, the Korn shell does not install into the root, nor is it statically linked.
My point was that it takes prior planning with specific intent and effort to make it so.



olli@ said:


> However, I still know the standard /bin/sh well enough to be able to work with it for 15 minutes in an emergency situation


I am quite familiar with /bin/sh.  In fact, the Bourne shell was my first shell, and I learned it on a hard copy DEC LA120.
I also to hope to limit my emergencies to 15 minutes, but still plan for the worst .


----------



## Vull (Aug 4, 2021)

I used ksh on AIX where it was the native default shell, and I loved it, but I always use the native default shell for interactive use. For scripting purposes I only use sh and that's mainly for cross-platform compatibility's sake and because it's a very fine shell.


----------



## gpw928 (Aug 4, 2021)

olli@ said:


> Maybe you haven’t worked at places that were extremely concerned about security.


I can't tell you where I have worked.  But I can say that security was taken seriously.


olli@ said:


> If things break in a way that you cannot log in normally anymore – including LDAP servers going down –, you can still boot into single-user mode. No root login required.


That might be a satisfactory solution if unscheduled downtime is permitted.


----------



## Alain De Vos (Aug 4, 2021)

For scripting it is key that you learn one shell. Because different shells have sometimes subtle nuaces and differences.
It really does not matter which shell you use. I use zsh because it has a lot of functionality. 
It is said you should use sh for portability. But every shell script is portable to the same shell.


----------



## olli@ (Aug 4, 2021)

gpw928 said:


> By default, the Korn shell does not install into the root, nor is it statically linked.
> My point was that it takes prior planning with specific intent and effort to make it so.


Well, yes, to a certain degree. In the case of zsh, I just compile the port with `STATIC=yes` and copy the resulting binary to /rescue. Not a big deal. As I mentioned previously, my update script does that automatically.


----------



## olli@ (Aug 4, 2021)

gpw928 said:


> That might be a satisfactory solution if unscheduled downtime is permitted.


If the services running on those machines are important, then there should be redundancy, e.g. a cluster of servers.


----------



## gpw928 (Aug 6, 2021)

olli@ said:


> If the services running on those machines are important, then there should be redundancy, e.g. a cluster of servers.


The issue is that your position (disabling root login) can require an unscheduled outage to resolve an issue -- whereas mine may not.  You have therefore increased the risk of service failure.
Multiplying the lines of service reduces the risk.  It does not remove it entirely, because circumstances may conspire to bring down an entire cluster of servers, all compromised for exactly the same reason.

If you are "extremely concerned about security", then disabling root login should not be recommenced without due consideration of the risk profile and mitigating factors.  You really do risk shooting yourself in the foot.

I am not saying that root logins should ever be considered routine.  But they can save you from an outage in an emergency.

An example of an environment that is extremely concerned about both security *and* continuity of service is where all system logs are collected and analysed in real time by an independent security team, so root logins are all observed (along with all sudo(8), and similar, activities) actively looking for any sign of malfeasance.


----------



## olli@ (Aug 6, 2021)

gpw928 said:


> The issue is that your position (disabling root login) can require an unscheduled outage to resolve an issue -- whereas mine may not.  You have therefore increased the risk of service failure.
> Multiplying the lines of service reduces the risk.  It does not remove it entirely, because circumstances may conspire to bring down an entire cluster of servers, all compromised for exactly the same reason.


I have to say I never experienced such a situation in 25 years. What kind of problem would require a root login, while at the same time it doesn’t cause a service downtime anyway? You mentioned LDAP – Well, if _all_ of your LDAP services are down at the same time, and root is your _only_ non-LDAP account (which would be a very bad idea, by the way), then your services are probably down anyway because authentication doesn’t work anymore.


----------



## gpw928 (Aug 7, 2021)

olli@ said:


> I have to say I never experienced such a situation in 25 years. What kind of problem would require a root login, while at the same time it doesn’t cause a service downtime anyway? You mentioned LDAP – Well, if _all_ of your LDAP services are down at the same time, and root is your _only_ non-LDAP account (which would be a very bad idea, by the way), then your services are probably down anyway because authentication doesn’t work anymore.


When an organiation gets large enough, the staff moves and changes need to be centrally managed so there is a highly secure single source of truth for accounts, authorisations, and password.

This is typically done with some combination or adaptation of Kerberos and LDAP, which rely on the network for their function.

There are many reasons why the LDAP servers may become inaccessible -- and those reasons go well beyond the risks that can be managed by clustering or running multiple lines of LDAP service.

There have been many occasions where I have seen a Unix host disappear from the network, suddenly and unexpectedly.

When you have hundreds of VMware servers, dozens are going to get replaced every year with the ongoing hardware replacement programme.  This provides a common source if problems -- because it's really hard to test properly before new server is commissioned.

When a Unix VM disappears from the network, your only way in to that Unix system is via the virtual console furnished by the VMware server.  You have no network, and therefore no LDAP authentication, so you can't login as yourself, and you absolutely need a local root login to diagnose the problem.  The most usual cause of this problem is a recent VMotion of your Unix VM to a new VMware server configured without the VLAN(s) your Unix VM needs to operate on its network(s).  The second most common cause is that the firewall team got the firewall rules wrong for the list of VMs that may be migrated to the new VMware server.  Host-based firewall rules on your Unix VM may also come into play, but that's far less common.

Such problems do not justify shutting down the Unix VM (and losing state and any stalled transactions) because the network is down and you can't login!  All you have to do is is fix the network issue(s).

Besides, shutting any system down without a pre-approved scheduled outage would most certainly result in a Quality Assurance non-conformance notice arriving in your in-box.

So, there exist circumstances where root logins are both desirable and necessary.


----------

