I know that enabling setuid on scripts has security issues and so is inactive by default, but expect that it works for executables. I created and executable which shows uid as an output following instructions described in this post: Allow setuid on shell scripts

But it returns same uid (1000) both before and after runningsudo chmod +s ./setuid-test. I think this means that setuid does not have any effects on my executable, why and how to solve?

The source code:

#include <stdio.h>
#include <unistd.h>
int main(int argc, char** argv) {
    printf("%d", geteuid());
    return 0;

Built and run with

$ gcc -o setuid-test setuid-test.c
$ ./setuid-test
$ sudo chown nobody ./setuid-test; sudo chmod +s ./setuid-test
$ ./setuid-test

When running ls -la, this is what I get:

me@me:~$ ls -la setuid-test
-rwsrwsr-x 1 nobody me 8572 Aug 19 16:39 setuid-test
  • 2
    Is the executable owned by a user other than the one you're running it as? (setuid doesn't mean change to root; it means change to the user that owns the executable.)
    – cjm
    Commented Aug 19, 2014 at 15:04
  • PHPLearner I think you need to involve a group/user in order to change the SUID of a file
    – ryekayo
    Commented Aug 19, 2014 at 15:05
  • @cjm me@me:~$ ls -la setuid-test ----returns---- -rwsrwsr-x 1 nobody me 8572 Aug 19 16:39 setuid-test Commented Aug 19, 2014 at 15:09
  • 7
    Your program works as expected on my Ubuntu 14.04 system if it's in my home directory, but not when it's in /tmp, because the parameters used to mount /tmp forbid setuid programs. Where is your program located? Commented Aug 19, 2014 at 15:11
  • 2
    Type df . in the directory to find the mount point, then mount | grep nameofmountpoint. Is there a nosuid flag listed there? Commented Aug 20, 2014 at 10:21

2 Answers 2


Most filesystems designed for Unix/Linux can be mounted with a nosuid attribute, which will prevent setuid or setgid binaries located on those filesystems from altering the effective uid or gid of a process. It's often used when mounting "untrusted" filesystems, those that are under the control of a non-administrator.

In your case, the filesystem you're using is type ecryptfs, which according to askubuntu: Error when running binary with root setuid under encrypted home directory enforces nosuid (and nodev) automatically, starting with the versions from a few years ago.

Here is a description of the reason for the change, from https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3409 :

Vincent Danen 2012-07-20 11:25:56 EDT
It was reported that the private ecryptfs mount helper (/sbin/mount.ecryptfs_private), which is setuid-root, could allow an unprivileged local user to mount user-controlled ecryptfs shares on the local system. Because the ecryptfs helper does not mount filesystems with the "nosuid" and "nodev" flags, it would be possible for a user to mount a filesystem containing setuid-root binaries and/or device files that could lead to the escalation of their privileges. This could be done via a USB device, if the user had physical access to the system.
Forcing MS_NOSUID and MS_NODEV mount flags was added to version 99 .

  • If the system allowed a user to mount a file-system that allows setuid, then it would be trivial to become root. 1) create an executable 2) elsewhere chown root, chmod +s 3) mount it 4) run executable Commented Jul 15, 2016 at 8:23

SetUID bit on executable allows to run executable at file owner (not superuser). To be able to run executable as root, execute:

sudo chown 0:0 ./setuid-test
  • Sure, but that's not the issue. It's possible to have a program that's setuid to a user other than root. In the scenario in the question, setuid-test should display nobody's UID. Commented Aug 19, 2014 at 22:57
  • @Gilles You are right. I expect that setuid-test displays nobody, not root Commented Aug 20, 2014 at 2:40
  • "SetUID bit on executable allows to run executable at file owner" and my file owner is nobody, thus I expect 65534 in return, but I see 1000 whoever be the owner! Commented Aug 20, 2014 at 2:52
  • 2
    Check the mount options of the filesystem on which your test program runs. If it is mounted with nosuid, then your program can't possibly work. Commented Aug 20, 2014 at 7:46
  • 1
    @countermode @MarkPlotnick mount | grep /home/me returns /home/me/.Private on /home/me type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=xxx,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=0123456789abcdef,ecryptfs_fnek_sig=fedcba9876543210) Commented Aug 20, 2014 at 17:43

You must log in to answer this question.

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