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]