I suppose an executable file with SetUID bit set should be running as its owner but I cannot really reproduce it. I tried the following.

$ cat prepare.sh
cp /bin/bash .
chown root.root bash
chmod 4770 bash # Verified
$ sudo sh prepare.sh
$ ./bash
$ id -u
$ exit
$ cat test.c
int main(){
    printf("%d,%d\n", getuid(), geteuid());
    return 0;
$ gcc -o test test.c
$ chmod 4770 test # Verified
$ sudo chown root.root test
$ ./test
$ # Why???


$ su
# ./bash
# id -u
# ./test
# exit
# exit

Note: The mount point has no nosuid nor noexec set.
Can anyone explain why it's failing to work on Ubuntu 16.04 LTS?

  • 3
    Possible duplicate of Allow setuid on shell scripts – Kusalananda Apr 18 '17 at 6:35
  • 3
    @Kusalananda it is not a script. – enzotib Apr 18 '17 at 6:39
  • 4
    The script is a bit confusing, but it's just a red herring. I suppose it's there to save two uses of sudo? There's a bug or a typo in it, though, the chmod is missing a file name. – ilkkachu Apr 18 '17 at 8:17

For the compiled executable, from man 2 chown:

When the owner or group  of  an  executable  file  are  changed  by  an
unprivileged user the S_ISUID and S_ISGID mode bits are cleared.  POSIX
does not specify whether this also should happen  when  root  does  the
chown();  the Linux behavior depends on the kernel version.

Reversing the chown and chmod order works for me:

$ sudo chmod 4770 foo
$ sudo chown root:root foo
$ stat foo
  File: 'foo'
  Size: 8712        Blocks: 24         IO Block: 4096   regular file
Device: 801h/2049d  Inode: 967977      Links: 1
Access: (0770/-rwxrwx---)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-04-18 15:15:15.074425000 +0900
Modify: 2017-04-18 15:15:15.074425000 +0900
Change: 2017-04-18 15:15:33.683725000 +0900
 Birth: -
$ sudo chmod 4777 foo
$ ./foo

In your first case, it's Bash that doesn't like being run as setuid.

If Bash is started with the effective user (group) id not equal to the real user (group) id,..., and the effective user id is set to the real user id.

See: Bash's manual on startup files, also Setuid bit seems to have no effect on bash .

In the second case, it's the order of chmod and chown that matters, as muru already answered. Changing the owner resets the setuid bit.

  • Oh, I didn't notice the OP was using the script setup a setuid bash. – muru Apr 18 '17 at 8:18

It could also be that the filesystem containing the test executable was mounted with the nosuid option; I have heard that newer distributions will do this by default for /tmp, and there are good arguments for applying it to /home as well. nosuid causes the kernel to ignore the setuid and setgid bits on all executables within the filesystem. (The unrelated thing that happens when you make a directory setgid is unaffected.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.