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

[John Aten]

Hi all,

I was able to boot in with Knoppix and correct my /etc/passwd and everthing 
went fine. I can't recommend Knoppix enough for anyone with a similar disaster. 
I then added the new bash to my /etc/shells, and now have the new build as the 
default for both accounts. 

I apologize for the slightly off topic post, but at the time I wasn't entirely 
sure that it was off topic.

Thanks for the suggestions and help!


On Oct 5, 2014, at 6:02 PM, Bob Proulx wrote:

> 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