My question is build on top of the answer of the question about SUID exploitation:

SUID not used after exploit

The person (official answer) is stating that:

Many popular implementations of sh drop privileges when they start up: they reset their effective UID to their real UID. This includes bash, dash, mksh and BusyBox sh, so on Linux you won't see anything else.

So my question is which shells don't perform such critical security checks?

I tested it on my Ubuntu machine (18.04) and it seems that all shells are implementing such security checks:

ubuntu@ubuntu: cat /etc/shells
# /etc/shells: valid login shells

If I run (make simplest possible check):

root@ubuntu: echo "secret" > root-file.txt
root@ubuntu: cp /bin/bash /tmp/foo && chmod u+s /tmp/foo
lowpriv@ubuntu: ./tmp/foo -c "cat root-file.txt"

I get for all shells (as expected):

cat: root-file.txt: Permission denied

So it works for all standard (shipped with Ubuntu) Ubuntu-shells.

  • 1
    In my experience, setting the EUIDs doesn't escalate the privileges. That's why we use setresuid(0,0,0) (real ID, effective ID, save set-user ID), to escalate to root or another user. If you're targeting a different user, you need to make sure that you use their ID in your exploit rather than 0. This is natural behavior of linux. Commented Aug 4, 2019 at 20:13
  • 1
    Note that with Bash you can override this behavior using the -p command line switch. An attacker who manages to create a suid shell can still benefit from the suid if they specify that flag.
    – gowenfawr
    Commented Aug 4, 2019 at 23:56

1 Answer 1


At least fish, ksh93, yash and zsh are available in Ubuntu, but not installed by default, and don't drop privileges when they start. Perl and Python are installed by default and don't drop privileges.

This is not a “critical security check”. If an adversary can cause an interpreter to be setuid, they can also run code as that user. If they can inject code into a setuid program and they want to run a shell, they can upload their own interpreter that doesn't have a check, or leverage some non-shell interpreter such as perl, or run native code.

I think some shells have historically done this to prevent setuid scripts, which are a bad idea because it's very difficult to make a setuid shell script robust against all possible environment variables. They keep doing this today for backward compatibility, even though modern unices don't honor the setuid bit on scripts.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .