Setuid, SUID bit not providing root privileges

Question

I've written and compiled a short program to allow any user to change the contents of my /sys/class/backlight/intel_backlight/brightness file, but I fail to escalate their permissions. What could I be missing.

#include <stdio.h>
#include <stdlib.h>
#define FILENAME "/sys/class/backlight/intel_backlight/brightness"
int main (int argc, char * argv[])
{
 int res;
 setuid(0); // I didn't intend to keep this, but I included it just in case
 printf("euid %d\n", geteuid());
 system("whoami");
 // Attempt to open FILENAME; print "Can't open..." on failure
}

Yet, whoami consistently returns exampleuser instead of root, and the program consistently fails to open the output file.

I compile it and set the uid bit then run the program:

$ gcc -o example.bin example.c # compile
$ sudo chown root:root example.bin # set owner & group
$ sudo chmod 4770 example.bin # set uid bit
$ ./example.bin 75 # execute
euid 1000
exampleuser
Can't open output file /sys/class/backlight/intel_backlight/brightness

The target output file does exist:

$ ls -l /sys/class/backlight/intel_backlight/brightness
-rw-r--r-- 1 root root 4096 May 2 07:57 /sys/class/backlight/intel_backlight/brightness

I'm running Ubuntu 14.04 LTS

• Celada: Is the filesystem on which example.bin is located mounted with nosuid? Also, I suggest id -a as a more comprehensive test command instead of whoami. I am not sure but I think who and/or whoami obtain information from utmp which could cloud the facts.

Answer 1

Either the filesystem is doesn't support setuid executables (because it's mounted with the nosuid option, or because it's a FUSE filesystem mounted by a non-root user), or there is a security framework such as SELinux or AppArmor that prevents setuid here (I don't think Ubuntu sets up anything like this though). That, or you didn't actually run these commands — you've made the file non-executable by others, so they'd only work if you were in the root group, which you shouldn't be.

This isn't a good way to do it anyway. It's a lot simpler to change the permissions on the file.

chgrp users /sys/class/backlight/intel_backlight/brightness
chmod g+w /sys/class/backlight/intel_backlight/brightness

Use a group that you're a member of, if you aren't a member of the users group.

Add these commands to /etc/rc.local or some other script that is executed near the end of the boot sequence.

• Jellicle: Thanks for the alternative design. As for the nosuid option, mount reveals that the device on which example.bin resides has no such restriction: /dev/sda5 on / type ext4 (rw,errors=remount-ro). I don't believe I'm using any unusual frameworks except for encryption of the home folder with encryptfs-utils.
• Jellicle: I did run the commands, and I am in the root group, for better or worse.
• Jellicle: The file I wish to modify, however, is on a device mounted with nosuid. I wouldn't expect that to make a difference, but do you know otherwise?
• Gilles 'SO- stop being evil': @JellicleCat Ah, so the file is on a filesystem which doesn't support setuid — it's on ecryptfs (if it's on the encrypted part, it isn't on the / filesystem). I forgot to mention that case.
• Gilles 'SO- stop being evil': @JellicleCat Is example.bin in your (encrypted) home directory, or on the / filesystem? The fact that /sys doesn't support setuid is irrelevant.