[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-bash] New bash build as default shell
Re: [Help-bash] New bash build as default shell
Wed, 8 Oct 2014 14:55:05 -0500
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
> 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.