FS#43404 - [filesystem] package contains configuration files referencing to pre-/usr/bin merge file locations
Attached to Project:
Arch Linux
Opened by Marty Plummer (ntzrmtthihu777) - Saturday, 10 January 2015, 22:06 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 15 March 2015, 14:10 GMT
Opened by Marty Plummer (ntzrmtthihu777) - Saturday, 10 January 2015, 22:06 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 15 March 2015, 14:10 GMT
|
Details
Description:
/etc/shells contains only /bin/bash and /bin/sh Additional info: Just a small annoyance, but if one sets up a new user and sets their shell to /usr/bin/bash (in accordance with the true filesystem location of the bash binary) one cannot login to that user without either changing the shell to /bin/bash or manually editing /etc/shells (probably is some 'proper' way to do that, but I don't know it right now) In addition, many users in /etc/passwd use the old pathnames before the huge /usr/bin merge for their shells. Newly installed shell packages add both paths, e.g. /bin/zsh and /usr/bin/zsh for ssh. I just think we should follow through with the logical extension of the /usr/bin merge. Steps to reproduce: 1. Add a new user, setting shell to /usr/bin/shell 2. Attempt to login several times, checking and double checking that you are typing the password correctly. 3. Proceed to be very frustrated troubleshooting the issue before you realize that /usr/bin/shell doesn't exist in /etc/shells 4. Feel dumb and fire up $EDITOR and fix /etc/shells |
This task depends upon
Closed by Dave Reisner (falconindy)
Sunday, 15 March 2015, 14:10 GMT
Reason for closing: Not a bug
Additional comments about closing: /bin/bash is the canonical name of the shell -- I see no compelling reason to deviate from this. You're responsible for your own system.
Sunday, 15 March 2015, 14:10 GMT
Reason for closing: Not a bug
Additional comments about closing: /bin/bash is the canonical name of the shell -- I see no compelling reason to deviate from this. You're responsible for your own system.
I don't see much point in "fixing" this. You wouldn't use /usr/bin/bash as a shebang, so why use /usr/bin/bash as your shell?
This must be "fixed" at the same time to avoid creating users that can't log in afterwards.
I'm so annoyed, I want to avoid saying something rude. The thing is, the damn file path is "/usr/bin/bash", and NOT "/bin/bash".
I was just hand-tweaking my password file after a "filesystem" package upgrade on an old machine, and then I couldn't log in! I'm lucky I had a Debian backup partition, and I'm lucky that Marty filed this bug report. And that's after wasting time checking my password encryption.
It would be less problematic to see both "/usr/bin/bash" and "/bin/bash" in "/etc/shells". But insisting on using obsolete path names is just inconsiderate.
Of course, it could be argued that this is a bug in "login", not following symbolic links when matching against /etc/shells. But then, following symbolic links can be a security issue. So then, why would _following_ symbolic links NOT be a security issue when actually executing the shell?
It seems kind of silly, to go to the trouble of checking for a "valid" shell path _without_ symbolic links, and then _executing_ that shell path _with_ symbolic links.
I filed a bug upstream against util-linux:
Bug 93981 - [util-linux] login, shells, file paths, and the /usr/bin/ merge
https://bugzilla.kernel.org/show_bug.cgi?id=93981