Re: [Help-bash] New bash build as default shell

[Bob Proulx]

John Aten wrote:
> I am new to the list, and was wondering if anyone had any ideas
> about the following problem.

This almost has more in common with Debian than with Bash.  And so I
almost suggest the debian-user mailing list for discussion. :-)

> I am running Debian Wheezy on a Dell Inspiron laptop. I just built
> bash 4.3.29 from source. I wanted to change my root and one user
> account to use it as the default shell. I ran sudo chsh and entered
> /usr/local/bin/bash, and everything was fine. I could log in and
> out, run commands, and the $SHELL and $BASH_VERSION environment
> variables confirmed the change.

Sure.  You were root when you made that chsh change.  So of course it
was allowed and all was okay.  Root is the superuser and not
restricted from doing this.  But...

> Things got hinky, though when I tried to change my regular, non-root
> user account. While logged in as my regular user, I entered chsh,
> but when I typed in the path, it says that I had entered an invalid
> shell.

Right.  The list of valid shells is /etc/shells.  Since you didn't add
/usr/local/bin/bash to that list it isn't considered a valid shell.
All is working as it is designed to work.  If you want to make another
shell such as your self-compiled one accepted as a valid shell you
should add it to the /etc/shells list.  You can find information about
this in the "man chsh" documentation.

> I tried sudo chsh, and the same. I was perplexed by this, as
> it seemed perfectly valid when I ran it as this user by typing the
> path into the command line of the previous default shell. Commands
> run normally, and $BASH_VERSION returns the right number. I tried to
> change my regular user's shell again and got the same error. I
> triple checked the path, and tried again, this time while logged in
> as root. It then returned:
> 
> chsh: PAM: Authentication failure

Many things will check that the shell is a valid login shell from the
list in /etc/shells before the login is allowed.  Consider that people
disable accounts by changing the login shell to one not in /etc/shells
specifically to disable the login.

> I logged in as root and changed the shell for my regular user
> account in /etc/passwd, but after this I couldn't log in to my
> regular user account at all.

I expect that a typo error of some sort was made.  Editing the file
manually will work.  But if a mistake is made then of course it
depends upon the mistake.

> At first it gave me a 'login incorrect' error, but on repeated
> attempts it would give what looks like a 10 or 15 line message, but
> the screen clears so quickly I can't read it.

I find the screen clearing extremely annoying and not an enhancement
to security.  Others disagree and have made it so that the screen is
cleared in several different places.  Grr...  One place is that newer
getty clears the screen by default unless --noclear is given to
getty.  (Plus there is .bash_logout with a clear often too.)

I always disable the screen clearing.  I am okay accepting the
responsibility that if I leave something security or privacy related
on the screen that it is my responsibility to clear it manually if I
don't want it displayed when I log off.

To disable getty clearing the screen add --noclear to the /etc/inittab
such that it looks like this.  For Debian Wheezy 7 that you specified
and earlier but not for Jessie 8 or later since systemd does this
differently.  After editing the file send a SIGHUP to init to have it
re-read the file.

  1:2345:respawn:/sbin/getty --noclear 38400 tty1

Otherwise when the shell exits (due to the errors) the getty will
respawn and it will clear the screen.

> I logged in as root and changed my regular user's default shell back
> to the previous /bin/bash, and now it works fine.

I suspect a typo in your previous edit.  Or an error in your path.  Or
an error in your shell.  Because using /usr/local/bin/bash as a login
shell works perfectly fine.  You said it worked fine for you when you
did it to the root user.  So the path was fine.

If it works as a login shell for root but not as a non-root user then
one possible problem is that the file permissions do not allow
non-root users to execute the shell.  But there are many errors
possible.  I couldn't guess all of them.

Bob