Problem by changing the rootshell [Archive]

Ishildur

February 12th, 2009, 17:10

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

February 12th, 2009, 17:12

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

graudeejs

February 12th, 2009, 17:27

pw usermod username -s /path/to/shell

anomie

February 12th, 2009, 18:42

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

February 13th, 2009, 05:50

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

February 13th, 2009, 10:08

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

February 13th, 2009, 10:19

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

February 13th, 2009, 10:21

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

February 13th, 2009, 11:58

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

February 13th, 2009, 20:10

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

February 16th, 2009, 01:38

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).

February 16th, 2009, 18:20

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@

February 16th, 2009, 18:38

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

anomie

February 16th, 2009, 19:20

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.

March 23rd, 2009, 21:44

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

March 23rd, 2009, 21:47

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

March 24th, 2009, 12:54

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

March 24th, 2009, 13:40

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.

SirDice

March 24th, 2009, 13:44

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

March 24th, 2009, 18:53

_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

March 24th, 2009, 19:02

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?)

March 24th, 2009, 20:35

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

March 25th, 2009, 13:36

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

March 25th, 2009, 13:45

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

SirDice

March 25th, 2009, 13:53

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@

March 25th, 2009, 14:36

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@

March 30th, 2009, 07:04

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

March 30th, 2009, 19:10

Mel_Flynn

March 30th, 2009, 23:47

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?

March 31st, 2009, 00:05

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

March 31st, 2009, 03:55

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: "It's not my fault, I did not change root's shell!"

phoenix

April 1st, 2009, 16:56

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

April 2nd, 2009, 10:36

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

April 2nd, 2009, 19:57

... 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 (http://forums.freebsd.org/showpost.php?p=18352&postcount=29) by assuming that the shell of choice is statically linked and on the / filesystem. Most folks don't go to that effort.