Problem by changing the rootshell

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 ;-)
 
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.
 
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. :>
 
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...
 
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.
 
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.
 
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.
 
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:
Code:
$ 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
 
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).
 
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.
 
when your system breaks (e.g. /usr/ won't be available), you will not be able to log in...
 
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.
 
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 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.
 
MG said:
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.

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.
 
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.
 
_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).
 
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?)
 
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.
 
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.
 
The remote command is executed in a shell (login -> bash -> sh), which may not be there when bash is broken.
 
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?
 
Back
Top