What Shell Am I Using?

  % help
  zsh: command not found: help

Well, it kinda works. Just not in the way you might have hoped :P But the output lets you know that you are running zsh.

And to find out the version:

  % echo $ZSH_VERSION
  5.7.1

(Assuming no-one has been silly and overridden the value of said environment variable in their zshenv file or something. But if we assumed that to be likely then we should also assume that someone using bash had aliased 'help' to something else too, so I think it is fair to assume that no-one had done that.)

> Not sure it macOS has as much info in /proc?

macOS does not have procfs

Do you have any resources about /proc you'd recommend?

does not work in Fish Shell.

  fish: $$ is not the pid. In fish, please use $fish_pid.

  readlink -e /proc/$$/exe

                     ^

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)

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.

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

* scponly: https://linux.die.net/man/8/scponly

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

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

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

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.

This made my morning. LoL

the article is about finding the specific version and path

which "$(echo $0)" should work no matter the invokation ;p if full path, it still returns full path, if just "bash" or such it finds it from $PATH, badoom!

Apparently it does not:

   ~ % which fstat
   fstat not found

A quick and dirty way to detect a modified executable on Linux, is to compare /proc/$pid/exe and its target.

    $ readlink /proc/$$/exe
    /bin/bash (deleted)

    $ sha256sum /proc/$$/exe $(readlink /proc/$$/exe)
    16a94220a1cf204076640914f09cf0af59da07771819e7eb9671216643296d73  /proc/665119/exe
    16a94220a1cf204076640914f09cf0af59da07771819e7eb9671216643296d73  /bin/bash
    sha256sum: '(deleted)': No such file or directory

If the unlinked executable has been replaced by a new executable with the same content, they will have the same checksum, this could possibly happen if the package has been reinstalled, which is unlikely to occur. If the original executable is nowhere to be found on the disk, at least you can...

    $ cp /proc/$$/exe  shell_bin_under_analysis
    
    $ strings shell_bin_under_analysis | grep version
    GNU bash, version %s-(%s)
    GNU bash, version %s (%s)
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    @(#)Bash version 5.0.16(1) release GNU

    $ strings shell_bin_under_analysis | grep zsh
    # [...]
    zsh-5.8-0-g77d203f
    # [...]

You can temporarily alter environment variables like this:

  PATH= /path/to/command

That will run /path/to/command with the PATH variable unset.

/usr/local/bin is on PATH by default on macOS.

I think you're missing the point. The author wants to know the location of the binary of the shell he's currently running. Changing PATH doesn't help answering this question: it only changes what `which` displays, but the point of the author is that `which` is not the correct tool to help answering this question.

Not on macOS

+1. On Linux, with /proc, it's just much easier.

As the author notes in the 2nd section, that will return the location of the binary in the user path, which is not necessarily the one that is currently running.