# Why no /usr/sin/sh in /etc/shells **URL:** \ **Category:** SLES Configure-Administer\ **Created:** [April 30, 2019, 5:25pm UTC](https://forums.suse.com/t/why-no-usr-sin-sh-in-etc-shells/33880 "2019-04-30T17:25:57Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![raduntsev](https://avatars.discourse-cdn.com/v4/letter/r/ac8455/32.png) [@raduntsev](https://forums.suse.com/u/raduntsev)\ **Post date:** [April 30, 2019, 5:25pm UTC](https://forums.suse.com/t/why-no-usr-sin-sh-in-etc-shells/33880/1 "2019-04-30T17:25:57Z")
Hello, recently I faced with the issue when user who has configured shell /usr/bin/sh wasn’t able to logon via ftp (vsftpd). When checked pam modules found no useful and started comment them one by one. On commented pam\_shells.so user logged on successfully. Then, when checked content of /etc/shells I was surprised when found no /usr/bin/sh, but /bin/bash exists (both are part of bash-4.3-83.23.1.x86\_64) Therefore I have a questions: why one of default bash shell paths is not part of valid logon shells and is there any concerns to amend /etc/shells with /usr/bin/sh? Thank you in advance. Regards, Ivan # rpm -qf /etc/shells aaa\_base-13.2+git20140911.61c1681-38.13.1.x86\_64 # cat /etc/SuSE-release SUSE Linux Enterprise Server 12 (x86\_64) VERSION = 12 PATCHLEVEL = 3 # This file is deprecated and will be removed in a future service pack or release. # Please check /etc/os-release for details about this release. # cat /etc/os-release NAME=“SLES” VERSION=“12-SP3” VERSION\_ID=“12.3” PRETTY\_NAME=“SUSE Linux Enterprise Server 12 SP3” ID=“sles” ANSI\_COLOR=“0;32” CPE\_NAME=“cpe:/o:suse:sles\_sap:12:sp3” ---
**Author:** ![system](https://us1.discourse-cdn.com/flex022/uploads/suse/original/2X/5/5012ba89e3ffb5220dac47d5ea0ba032e2fe1cb6.png) [@system](https://forums.suse.com/u/system)\ **Post date:** [April 30, 2019, 10:29pm UTC](https://forums.suse.com/t/why-no-usr-sin-sh-in-etc-shells/33880/2 "2019-04-30T22:29:45Z")
On 04/30/2019 08:34 AM, raduntsev wrote:[color=blue] > Hello, > recently I faced with the issue when user who has configured shell > /usr/bin/sh wasn’t able to logon via ftp (vsftpd). > When checked pam modules found no useful and started comment them one by > one. On commented pam\_shells.so user logged on successfully. > Then, when checked content of /etc/shells I was surprised when found no > /usr/bin/sh, but /bin/bash exists (both are part of > bash-4.3-83.23.1.x86\_64) > Therefore I have a questions: why one of default bash shell paths is not > part of valid logon shells and is there any concerns to amend > /etc/shells with /usr/bin/sh?[/color] In a couple decades of work, I’ve never noticed somebody use anything like /usr/bin/sh as a login shell. Why was that done? bash, or Bourne Again Shell, is the success for the Bourne Shell (sh), and was its successor as of multiple decades ago. For that reason the bash package replaces the other, and used to have some symlinks (not real files I believe) in place so that scripts still pointing to /bin/sh (or maybe /usr/bin/sh) will seamlessly work within bash. It would seem that after years of that somebody has finally decided to make it clear that ‘sh’ s gone and bash is its replacement. Maintaining old shells (e.g. for the maintainer of the aaa-base package and SUSE for SLES and openSUSE distributions) takes time testing everything to make sure it all works . Since this is a corner case, they likely decided it would be better to trim the code and focus on things that matter more, and the account you are using is now ready to update to use /bin/bash directly (vs. via a symlink). – Good luck. If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below. If you want to send me a private message, please let me know in the forum as I do not use the web interface often. ---
**Author:** ![raduntsev](https://avatars.discourse-cdn.com/v4/letter/r/ac8455/32.png) [@raduntsev](https://forums.suse.com/u/raduntsev)\ **Post date:** [May 1, 2019, 12:04pm UTC](https://forums.suse.com/t/why-no-usr-sin-sh-in-etc-shells/33880/3 "2019-05-01T12:04:18Z")
Thanks for quick and full reply, but unfortunately I don’t know why certain user has /usr/bin/sh as shell and unable to find it fast. Also due the server has quite complected configuration with multiple scripts and hosts production SAP I don’t want to touch user’s shell and workarounded it by modifying shells file (it is better to modify pam config). But initial question has another issue plane: it has no aim to concern about supporting old shells, bash suits fine, but due to native bash package has default symlinks and in same time it is trusted shell why to not include its symlinks to shells file, or simply remove the links from bash package? In my question I guessed that there could be some security concern and therefore want to know how urgent I should plan to replace user’s shell. Also next aaa-base update could be concern, will it replace my shells? In same time if no security reason to not have default bash (or other native shell’s) symlink in shells file I don’t see any reasons and maintenance overhead to have related record in the file until official shell package has the symlink. [QUOTE=ab;57565]On 04/30/2019 08:34 AM, raduntsev wrote:[color=blue] > Hello, > recently I faced with the issue when user who has configured shell > /usr/bin/sh wasn’t able to logon via ftp (vsftpd). > When checked pam modules found no useful and started comment them one by > one. On commented pam\_shells.so user logged on successfully. > Then, when checked content of /etc/shells I was surprised when found no > /usr/bin/sh, but /bin/bash exists (both are part of > bash-4.3-83.23.1.x86\_64) > Therefore I have a questions: why one of default bash shell paths is not > part of valid logon shells and is there any concerns to amend > /etc/shells with /usr/bin/sh?[/color] In a couple decades of work, I’ve never noticed somebody use anything like /usr/bin/sh as a login shell. Why was that done? bash, or Bourne Again Shell, is the success for the Bourne Shell (sh), and was its successor as of multiple decades ago. For that reason the bash package replaces the other, and used to have some symlinks (not real files I believe) in place so that scripts still pointing to /bin/sh (or maybe /usr/bin/sh) will seamlessly work within bash. It would seem that after years of that somebody has finally decided to make it clear that ‘sh’ s gone and bash is its replacement. Maintaining old shells (e.g. for the maintainer of the aaa-base package and SUSE for SLES and openSUSE distributions) takes time testing everything to make sure it all works . Since this is a corner case, they likely decided it would be better to trim the code and focus on things that matter more, and the account you are using is now ready to update to use /bin/bash directly (vs. via a symlink). – Good luck. If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below. If you want to send me a private message, please let me know in the forum as I do not use the web interface often.[/QUOTE] ---
**Author:** ![system](https://us1.discourse-cdn.com/flex022/uploads/suse/original/2X/5/5012ba89e3ffb5220dac47d5ea0ba032e2fe1cb6.png) [@system](https://forums.suse.com/u/system)\ **Post date:** [May 1, 2019, 4:20pm UTC](https://forums.suse.com/t/why-no-usr-sin-sh-in-etc-shells/33880/4 "2019-05-01T16:20:30Z")
On 05/01/2019 03:14 AM, raduntsev wrote:[color=blue] > Thanks for quick and full reply, but unfortunately I don’t know why > certain user has /usr/bin/sh as shell and unable to find it fast. Also > due the server has quite complected configuration with multiple scripts > and hosts production SAP I don’t want to touch user’s shell and > workarounded it by modifying shells file (it is better to modify pam > config).[/color] I’m glad it is working. Since that file is under /etc it is probably safe to assume that you can edit it like this and work properly for the most part. [color=blue] > But initial question has another issue plane: it has no aim to concern > about supporting old shells, bash suits fine, but due to native bash > package has default symlinks and in same time it is trusted shell why to > not include its symlinks to shells file, or simply remove the links from > bash package?[/color] As mentioned before I"m guessing it was a cleanup effort. If somebody who maintains /etc/shells (aaa\_base in our case) puts code into it, then they should test that code. How much testing should be done per shell? Just a login? A login via TTY and another via SSH? Another from within another shell? Another with ‘su’? Another with ‘sudo’? Another with each graphical environment? Taking out old code is a good idea; some have said that work is not done when you stop adding things, but is done when you stop removing things (implying unnecessary things, bad things, etc.). On my really-not-new openSUSE 12.x box I do not have /usr/bin/sh so either it was never there on my system, or it was gone a long time ago with some earlier patch. [color=blue] > In my question I guessed that there could be some security concern and > therefore want to know how urgent I should plan to replace user’s shell. > Also next aaa-base update could be concern, will it replace my shells?[/color] I do not know of one, though using an ancient shell like sh instead of bash would probably not be a great idea from a security standpoint. Since things like /usr/bin/sh are just symlinks to /bin/bash that is not a huge risk on your system (I presume yours has a symlink like other systems I’ve checked), but then that might justify using /bin/bash directly even more since that’s really what you are using. [color=blue] > In same time if no security reason to not have default bash (or other > native shell’s) symlink in shells file I don’t see any reasons and > maintenance overhead to have related record in the file until official > shell package has the symlink.[/color] Yes, you’re probably fine having it there; symlinks on their own should not be a big deal or have big security implications for things like this (public executable code), though I think you’re waiting for the wrong thing if you are waiting for somebody to add /usr/bin/sh to /etc/shells when that appears to be something old and deprecated rather than something new. /bin/bash is the path to use, and your user should use it. – Good luck. If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below. If you want to send me a private message, please let me know in the forum as I do not use the web interface often.