PDA

View Full Version : SLES 12 SP3 Why no /usr/sin/sh in /etc/shells



raduntsev
30-Apr-2019, 15:25
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"

ab
30-Apr-2019, 20:29
On 04/30/2019 08:34 AM, raduntsev wrote:
>
> 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?

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.

raduntsev
01-May-2019, 10:04
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.


On 04/30/2019 08:34 AM, raduntsev wrote:
>
> 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?

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.

ab
01-May-2019, 14:20
On 05/01/2019 03:14 AM, raduntsev wrote:
>
> 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).

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.

> 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?

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.

> 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?

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.

> 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.

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.