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());
    // 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
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

  • 1
    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.
    – Celada
    May 2, 2015 at 20:07

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

  • 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. May 2, 2015 at 22:21
  • I did run the commands, and I am in the root group, for better or worse. May 2, 2015 at 22:25
  • 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? May 2, 2015 at 22:26
  • @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. May 2, 2015 at 22:27
  • 1
    @JellicleCat Is example.bin in your (encrypted) home directory, or on the / filesystem? The fact that /sys doesn't support setuid is irrelevant. May 2, 2015 at 22:29

You must log in to answer this question.

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