3 ms·

Something I’ve never understood about Unix: what’s the point of the shell field in passwd(5), /etc/shells and chsh(1) when one can just “exec /my/shell” in a st

Something I’ve never understood about Unix: what’s the point of the shell field in passwd(5), /etc/shells and chsh(1) when one can just “exec /my/shell” in a standard init file? Is it a hangover from the days when mainframes charged $0.12 per command?

Galanwe 6y ago
It's a bit of the same idea as "init", but for users. When a user logs in, you somehow need to know what to do next. What does it even mean "to log in" if not "run a program with my uid". Typically,you want to spawn a process that would allow the user to in turn run other processes. That's what the user default shell is. Trivia: changing the user default shell to /bin/false has been used quite a bit as a way to disallow a user from ssh into a machine (there are specific other steps to take into account when doing that which I won't cover here)
erik_seaberg 6y ago
Some users got a curses menu of stuff they may do, not a shell that requires knowing how to type a command (and that can run anything the filesystem lets them see). I've even seen users whose shell was pine, because email was all they used.
kristopolous 6y ago
Let me introduce you to a few friends, only 3 for now. Hopefully these will answer your question: * nologin: https://man7.org/linux/man-pages/man8/nologin.8.html https://man7.org/linux/man-pages/man8/nologin.8.html * scponly: https://linux.die.net/man/8/scponly https://linux.die.net/man/8/scponly * git-shell: https://git-scm.com/docs/git-shell https://git-scm.com/docs/git-shell If your policy is instead to fire up a full blown unrestricted bash shell, then hope the user doesn't exit your script before you swap it with a restricted shell, I've got some surprises for you. Even if you trust your users, every one of them is a potential doormat for a malicious user to wipe their feet on as they use leaked credentials. Moral of the story: the stuff is there for a reason and it's easy to use. Might as well do it. Most of the vintage useless stuff is long gone, if it's there it's probably still important.
pm215 6y ago
The ability to specify a shell in /etc/passwd is extremely long-standing: it is documented in the passwd(5) manpage of 1st Edition UNIX dated 1971 (https://www.tuhs.org/cgi-bin/utree.pl?file=V1/man/man5/passwd.5 https://www.tuhs.org/cgi-bin/utree.pl?file=V1/man/man5/passw...). My guess is that in 1971 you really didn't want to spawn a shell process unnecessarily on a multi-user pdp-11 (not because you're charged for it but because the machine is small and you don't want to waste ram or cpu). It also means you can say "use my locally compiled bugfixed shell binary that reads the same startup/init files as the standard system one", and you can have 'system' users with non-standard special-purpose shells -- 7th Ed's /etc/passwd (https://www.tuhs.org/cgi-bin/utree.pl?file=V7/etc/passwd https://www.tuhs.org/cgi-bin/utree.pl?file=V7/etc/passwd) has a uucp user whose shell is the uucico program, so a remote system can dial in, log in as 'uucp' and trigger file transfer. These days we'd probably also think about reducing 'attack surface' by not giving that kind of special purpose user a real shell even in passing (if a bug let them write to the shell's init files that turns write-file-as-user into remote-shell), but they wouldn't have been considering that in the early 70s...
kazinator 6y ago
But, no, one cannot just "exec /my/shell" if the shell in the password file is a program that doesn't offer such a command. Being able to assign a login shell to an account is an important security feature. It's not simply a user preference mechanism. It can be used to bind an account to a "restricted shell": https://en.wikipedia.org/wiki/Restricted_shell https://en.wikipedia.org/wiki/Restricted_shell When people use remote execution tools like (historically) rsh or ssh, the remote account's login shell is used. You can replace an account's login shell with a program that parses the commands and allows only very limited access. Here is an example such a script which I used for an account that accepted SSH tunnel connections for a remote desktop. (The remote Windows machine contained a "service" that called back to this machine via SSH, setting up a tunnel for accessing that Windows machine in the reverse direction.) #!/bin/bash if [ $# -ne 2 ] || [ "$1" != "-c" ] ; then echo interactive login not permitted echo "$@" >> ~/.log exit 1 fi case "$2" in rdp ) while true ; do sleep 3600 ; done ;; * ) echo that command is not allowed exit 1 ;; esac The only command allowed is "rdp", and what it does is put this "shell" to sleep, to keep the connection open. It's implemented as a built-in, right in the above case statement. If this script exits, the login session or remote command is terminated. The reason I did this is that the Windows machine held an unprotected SSH private key to be able to perform a password-less login to that Linux box. (This ran as a service, so even if the Windows machine were power-cycled, it would reconnect.) If someone got into the Windows box and discovered and understood the setup, and the Linux account were not protected by this script, they would be able to use the unprotected private key to ssh into it, or run ssh commands, or scp files, etc. This sort of thing has other applications; for instance, it could be used to give people real SSH git access, without shell access.

Galanwe 6y ago

It's a bit of the same idea as "init", but for users. When a user logs in, you somehow need to know what to do next. What does it even mean "to log in" if not "run a program with my uid". Typically,you want to spawn a process that would allow the user to in turn run other processes. That's what the user default shell is. Trivia: changing the user default shell to /bin/false has been used quite a bit as a way to disallow a user from ssh into a machine (there are specific other steps to take into account when doing that which I won't cover here)

erik_seaberg 6y ago

Some users got a curses menu of stuff they may do, not a shell that requires knowing how to type a command (and that can run anything the filesystem lets them see). I've even seen users whose shell was pine, because email was all they used.

kristopolous 6y ago

Let me introduce you to a few friends, only 3 for now. Hopefully these will answer your question: * nologin: https://man7.org/linux/man-pages/man8/nologin.8.html https://man7.org/linux/man-pages/man8/nologin.8.html * scponly: https://linux.die.net/man/8/scponly https://linux.die.net/man/8/scponly * git-shell: https://git-scm.com/docs/git-shell https://git-scm.com/docs/git-shell If your policy is instead to fire up a full blown unrestricted bash shell, then hope the user doesn't exit your script before you swap it with a restricted shell, I've got some surprises for you. Even if you trust your users, every one of them is a potential doormat for a malicious user to wipe their feet on as they use leaked credentials. Moral of the story: the stuff is there for a reason and it's easy to use. Might as well do it. Most of the vintage useless stuff is long gone, if it's there it's probably still important.

pm215 6y ago

The ability to specify a shell in /etc/passwd is extremely long-standing: it is documented in the passwd(5) manpage of 1st Edition UNIX dated 1971 (https://www.tuhs.org/cgi-bin/utree.pl?file=V1/man/man5/passwd.5 https://www.tuhs.org/cgi-bin/utree.pl?file=V1/man/man5/passw...). My guess is that in 1971 you really didn't want to spawn a shell process unnecessarily on a multi-user pdp-11 (not because you're charged for it but because the machine is small and you don't want to waste ram or cpu). It also means you can say "use my locally compiled bugfixed shell binary that reads the same startup/init files as the standard system one", and you can have 'system' users with non-standard special-purpose shells -- 7th Ed's /etc/passwd (https://www.tuhs.org/cgi-bin/utree.pl?file=V7/etc/passwd https://www.tuhs.org/cgi-bin/utree.pl?file=V7/etc/passwd) has a uucp user whose shell is the uucico program, so a remote system can dial in, log in as 'uucp' and trigger file transfer. These days we'd probably also think about reducing 'attack surface' by not giving that kind of special purpose user a real shell even in passing (if a bug let them write to the shell's init files that turns write-file-as-user into remote-shell), but they wouldn't have been considering that in the early 70s...

kazinator 6y ago

But, no, one cannot just "exec /my/shell" if the shell in the password file is a program that doesn't offer such a command. Being able to assign a login shell to an account is an important security feature. It's not simply a user preference mechanism. It can be used to bind an account to a "restricted shell": https://en.wikipedia.org/wiki/Restricted_shell https://en.wikipedia.org/wiki/Restricted_shell When people use remote execution tools like (historically) rsh or ssh, the remote account's login shell is used. You can replace an account's login shell with a program that parses the commands and allows only very limited access. Here is an example such a script which I used for an account that accepted SSH tunnel connections for a remote desktop. (The remote Windows machine contained a "service" that called back to this machine via SSH, setting up a tunnel for accessing that Windows machine in the reverse direction.) #!/bin/bash if [ $# -ne 2 ] || [ "$1" != "-c" ] ; then echo interactive login not permitted echo "$@" >> ~/.log exit 1 fi case "$2" in rdp ) while true ; do sleep 3600 ; done ;; * ) echo that command is not allowed exit 1 ;; esac The only command allowed is "rdp", and what it does is put this "shell" to sleep, to keep the connection open. It's implemented as a built-in, right in the above case statement. If this script exits, the login session or remote command is terminated. The reason I did this is that the Windows machine held an unprotected SSH private key to be able to perform a password-less login to that Linux box. (This ran as a service, so even if the Windows machine were power-cycled, it would reconnect.) If someone got into the Windows box and discovered and understood the setup, and the Linux account were not protected by this script, they would be able to use the unprotected private key to ssh into it, or run ssh commands, or scp files, etc. This sort of thing has other applications; for instance, it could be used to give people real SSH git access, without shell access.