# Problem by changing the rootshell



## Ishildur (Feb 12, 2009)

Hello
I've been trying to change the rootshell by adjusting the file /etc/passwd as following:

root:*:0:0:Charilie &:/root:/bin/csh

to

root:*:0:0:Charilie &:/root:/bin/sh

The problem is, that after rebooting, i'm still working with cshell:

echo $SHELL : /bin/csh

Has anyone an idea why?

Dear greetings from a absolut newbee ;-)


----------



## mfaridi (Feb 12, 2009)

Use this link
http://lantech.geekvenue.net/chucktips/jason/chuck/1035144363/index_html


----------



## graudeejs (Feb 12, 2009)

pw usermod username -s /path/to/shell


----------



## anomie (Feb 12, 2009)

Or: `# chpass -s /bin/sh`

This is fine. Do _not_ change root's shell to something that is not part of the base system, though.


----------



## mjguzik (Feb 13, 2009)

That's not a big problem. In case of broken root's shell one can log in as toor and fix things. Just be sure to set some password for that user. :>


----------



## Mel_Flynn (Feb 13, 2009)

mjguzik said:
			
		

> That's not a big problem. In case of broken root's shell one can log in as toor and fix things. Just be sure to set some password for that user. :>



err, nextboot "-s" -k kernel && shutdown -r now?
No need to give toor login access. For some things you it's good to make a trip to that colo that's miles away, just to remind yourself how stupid you were...


----------



## vivek (Feb 13, 2009)

Mel_Flynn said:
			
		

> err, nextboot "-s" -k kernel && shutdown -r now?
> No need to give toor login access. For some things you it's good to make a trip to that colo that's miles away, just to remind yourself how stupid you were...



heh ... Mel you nailed it correctly.


----------



## mjguzik (Feb 13, 2009)

But this requires access either physical or over kvm, while broken 3rd party shell (assuming that the basesystem works) can be fixed over the network after logging in as toor. 

In case you are able to write these commands that 3rd party shell probably works anyway (as you're using it). At least you can run e.g. /rescue/tcsh (in worst case) and proceed, no reason to go to single mode. Or maybe I'm missing something, I'm not sure if we are talking about the same issue.


----------



## SirDice (Feb 13, 2009)

Do NOT edit /etc/passwd directly. Either use vipw, pw or chsh commands to change parameters.

If you edit /etc/passwd directly some day you will end up with a nuked /etc/passwd and not being able to log on.


----------



## Mel_Flynn (Feb 13, 2009)

mjguzik said:
			
		

> But this requires access either physical or over kvm, while broken 3rd party shell (assuming that the basesystem works) can be fixed over the network after logging in as toor.



When updating shells, have a working second root login.
Verify that it works, before logging out.
Pray to the God of Uninterrupted Connections.



> In case you are able to write these commands that 3rd party shell probably works anyway (as you're using it).



See above, or:

```
$ sudo pw showuser root
root:*:0:0::0:0:Charlie &:/root:/bin/csh

$ sudo id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)

$ ls -al /bin/csh
ls: /bin/csh: No such file or directory
```


----------



## mjguzik (Feb 16, 2009)

1) If you're paranoid change toor's shell to /rescue/tcsh. Verify that you can log in as toor.
2) If you're paranoid change root's shell using toor's account. Log in as root. (I don't change root's shell everyday, so it's acceptable for me.)
3) After performing ports/system update, check root's/toor's (respectively)
ability to log in.
4) At any point of time tell the God of Uninterrupted Connections that you'll pray no more.

With root + toor combination you have two shells, and with root + normal user combination you probably have one, but let's say two anyway. So I don't see how not using 3rd party shell is safer (given steps written above).


----------



## MG (Feb 16, 2009)

anomie said:
			
		

> Or: `# chpass -s /bin/sh`
> 
> This is fine. Do _not_ change root's shell to something that is not part of the base system, though.



Why not? I use bash for years and have no problems with it. Just don't forget its in /usr/local/bin instead of /usr/bin. You  can even use your own script or binary as a login shell.

I prefer to give root the "nologin" shell and always su - to root from another user.


----------



## danger@ (Feb 16, 2009)

when your system breaks (e.g. /usr/ won't be available), you will not be able to log in...


----------



## anomie (Feb 16, 2009)

Moreover, when _bash_ breaks you will no longer be able to become root. Once you learn that lesson the hard way on a remote (not physically accessible) server, you will not make the mistake again.


----------



## MG (Mar 23, 2009)

anomie said:
			
		

> Moreover, when _bash_ breaks you will no longer be able to become root. Once you learn that lesson the hard way on a remote (not physically accessible) server, you will not make the mistake again.



always keep a spare user in your wheel group to do:

sudo /bin/sh

It's a bad idea to give direct remote access to the root account.
Someone might guess your password.


----------



## anomie (Mar 23, 2009)

MG said:
			
		

> It's a bad idea to give direct remote access to the root account.



Lest my comments in this thread be misinterpreted, I want to mention that I was not suggesting that.


----------



## pablo (Mar 24, 2009)

anomie said:
			
		

> Moreover, when _bash_ breaks you will no longer be able to become root. Once you learn that lesson the hard way on a remote (not physically accessible) server, you will not make the mistake again.


I use _bash_ for root. When I boot in single mode, so _/usr/local/bin/bash_ is unavailable, my intelligent system prompt me for login shell and suggest _/bin/sh_. I allways agree.
If it's 5 minute task then use sh;
elseif mount /usr; run bash;
when done reboot normal.
I think, it's no so dreadful.


----------



## SirDice (Mar 24, 2009)

MG said:
			
		

> always keep a spare user in your wheel group to do:
> 
> sudo /bin/sh
> 
> ...



You do not need to be a member of the wheel group to sudo. You do need to be a member of wheel to su.


----------



## SirDice (Mar 24, 2009)

pablo said:
			
		

> When I boot in single mode, so _/usr/local/bin/bash_ is unavailable, my intelligent system prompt me for login shell and suggest _/bin/sh_.


When booting to single user mode the system will always ask which shell to use. It doesn't matter if root's shell is available or not.


----------



## jb_fvwm2 (Mar 24, 2009)

_7, neither bash3 nor bash (4.) will build, despite
having the current /bash3/ already installed. They
each throw the same error.    (Just a note for
anyone with bash as their root shell).


----------



## anomie (Mar 24, 2009)

pablo said:
			
		

> I use _bash_ for root. When I boot in single mode, so _/usr/local/bin/bash_ is unavailable, my intelligent system prompt me for login shell and suggest _/bin/sh_. I allways agree.
> ...
> I think, it's no so dreadful.



And what if bash breaks, and you're not at an opportune time for bringing your system to single-user mode? (Or if your server is colocated across town/state/country?)


----------



## MG (Mar 24, 2009)

SirDice said:
			
		

> You do not need to be a member of the wheel group to sudo. You do need to be a member of wheel to su.



You are right. A user or group needs to be in (/usr/local)/etc/sudoers to sudo.


----------



## pablo (Mar 25, 2009)

anomie said:
			
		

> And what if bash breaks, and you're not at an opportune time for bringing your system to single-user mode? (Or if your server is colocated across town/state/country?)


H-m-m.
I will try connect through Putty with Remote Command set to "/bin/sh". Thus I will have "/bin/sh" as a shell, not a bash. (I hope
Then "su root -c /bin/sh".
It's seem to be work, but with working bash.
Just now I havn't brocken bash to test my idea.


----------



## DutchDaemon (Mar 25, 2009)

The remote command is executed in a shell (login -> bash -> sh), which may not be there when bash is broken.


----------



## SirDice (Mar 25, 2009)

Correct, the remote command function of ssh will NOT work when the user's shell is broken. I know, I've tried to circumvent a broken shell this way. It didn't work. Nor did any of the other tricks 

I ended up having to call (onsite) support to get them to fix it so I could login again.

Just leave root's shell as is.. You're supposed to use su/sudo anyway.. Why bother with root's shell?


----------



## lme@ (Mar 25, 2009)

danger@ said:
			
		

> when your system breaks (e.g. /usr/ won't be available), you will not be able to log in...



Actually, in Single User Mode you are prompted to enter the path to a valid shell, so you can always type /bin/sh there...


----------



## gordon@ (Mar 30, 2009)

Ishildur said:
			
		

> Hello
> I've been trying to change the rootshell by adjusting the file /etc/passwd as following:



I want to chime in here. Changing root's shell is a bad idea. Plain and simple. Let's say it again.

Changing root's shell is a bad idea.

If it really really annoys you to have to use csh versus sh, just do an exec /path/to/preferred/shell as your first command when you login as root.


----------



## phoenix (Mar 30, 2009)

Better yet, don't login as root.  Use sudo.

Use *su - -c /path/to/shell* if you really must login as root and use a different shell.

Or, configure/enable the toor user.  That's what it's there for (a second "root"/UID 0 account with a different shell).


----------



## Mel_Flynn (Mar 30, 2009)

gordon@ said:
			
		

> I want to chime in here. Changing root's shell is a bad idea. Plain and simple. Let's say it again.
> 
> Changing root's shell is a bad idea.
> 
> If it really really annoys you to have to use csh versus sh, just do an exec /path/to/preferred/shell as your first command when you login as root.



Less dogma please. Having csh as root's shell has been a bad idea for ages, yet no one does anything about that. If you know the pitfalls of changing a root shell, you can easily work around them (WITH_STATIC_$SHELL=yes, PREFIX=/). It is also trivial to change root's shell back to csh for the purpose of bugreporting or checking if your shell causes the error with your foo program.

Let's hear some real arguments why changing root shell is a bad idea, and let's assume that the prefered shell is located on / partition and statically linked. Like: what in base system assumes root shell is csh?


----------



## MG (Mar 31, 2009)

phoenix_rizzen said:
			
		

> Better yet, don't login as root.  Use sudo.
> 
> Use *su - -c /path/to/shell* if you really must login as root and use a different shell.
> 
> Or, configure/enable the toor user.  That's what it's there for (a second "root"/UID 0 account with a different shell).



Strange, in /etc/passwd they call him the "Bourne again Superuser".
No idea what this has to do with bash or it's creator.

I tried in xterm/bash:
su - -c /bin/csh
su: only root may use -c

according to the su manpage the -c option is for root to
start a shell with specific user or group permissions. 
But if you are already root why not just type csh to get your shell?


----------



## fronclynne (Mar 31, 2009)

*blame the cat*



			
				Mel_Flynn said:
			
		

> Less dogma please.


It's the only thing seperating us from the catma?

In any case, the best reason is that when I ask why I cannot log-in as root any more (some 5 months from now) I can clearly say:





			
				lvl5 Cellar Troll (6d3 +10 gas damage per round) said:
			
		

> "It's not my fault, I did not change root's shell!"


----------



## phoenix (Apr 1, 2009)

MG said:
			
		

> Strange, in /etc/passwd they call him the "Bourne again Superuser".
> No idea what this has to do with bash or it's creator.



Originally, way back in the annals of history, toor was created to allow people to use a UID 0 account with bash set as the default shell.  Hence the name set in /etc/passwd.


----------



## Mel_Flynn (Apr 2, 2009)

fronclynne said:
			
		

> It's the only thing seperating us from the catma?


No, it allows us to create informed decisions. The reason I change root shell is that I know more about the ksh and bash shell then the csh shell and that makes me more productive in the cases I need to log in and root and fix problems.
I could probably shape csh's behavior to be as productive as bash/ksh, but since no one gives any real answer as to why root's shell should be unchanged, these changes might as well cause the breakage of the mystical system that requires root's shell to be csh.


----------



## anomie (Apr 2, 2009)

Mel_Flynn said:
			
		

> ... since no one gives any real answer as to why root's shell should be unchanged, these changes might as well cause the breakage of the mystical system that requires root's shell to be csh.



Well, you changed the rules a bit by assuming that the shell of choice is statically linked and on the / filesystem. Most folks don't go to that effort.


----------

