# sysfs (/sys) permissions?

## Sadako

Hey, I wanted to change the permissions of a particular few virtual files under /sys to enable certain non-root users write to them, so I added the following to /etc/conf.d/local.start;

```
chgrp powernow /sys/devices/system/cpu/cpu[0-3]/cpufreq/scaling_governor

chmod g+w /sys/devices/system/cpu/cpu[0-3]/cpufreq/scaling_governor
```

This worked exactly as I wanted, however the group ownership seems to be periodically reset to "root" after some time, and I have no idea where this is coming from...

Anyone know if this is an in-kernel thing, or something like udev (I don't think I'm running any other daemons which could be responsible), and anyone know a way around it?

As the group writable permissions are not reset, I could just make them world writable, which would at least allow me to do what I wanted, but I'd prefer to retain some access control over it...

Thanks in advance for any help or insight.

----------

## aCOSwt

Well, I am not sure I perfectly understood your question, nor understood what you are in final wishing to achieve.

I answer just not to let you alone on this one...   :Very Happy: 

My opinion is that there is no case where you should authorize a non root user to directly write to things such as /sys/devices/system/cpu/cpu[0-3]/cpufreqscaling_governor.

If you want non root users to act on this kind of things, this should be made through some dedicated shell script or binary owned by root and to which you set the setuid flag on exec or allow its use via sudo.

Then there is just no need for fiddling with /sys/... thingies group.

BTW, in case this script is already written... Did you look into the sys-power/cpufrequtils package if you had some function matching what you finally want to achieve ?

----------

## Sadako

Hey aCOSwt, thx for the reply.

While I agree with pretty much everything you said in principle, setting a script SUID quite simply doesn't work, the script's interpreter is what needs to be set SUID, which would be a disastrous move from a security perspective.

What I'm actually trying to do is make it so that non-root users can change the cpu frequency scaling governor, so they can switch it from "powersave", statically set to the lowest freq, "ondemand", which idles at the lowest freq and dynamically scales as required under load, and "performance", which statically sets it to the highest available frequency.

I want to be able to change this without having to su to root, also I want to be able to switch from ondemand to powersave when I start my screen locker from a keybinding, and set it back to ondemand when unlocked again (incidentally, the screen locker I'm using is alock, which is the only one which uses pam, therefore doesn't need to be SUID...).

This I can easily do with a wrapper script around the screen locker, provided I don't need root perms to write to those files...

The best solution of course would be to write my own utility to do this in C, but I'm not really a programmer, and wouldn't feel comfortable writing something which would have to be set SUID.

So, while I agree that non-root users should not have any write access to anything under /sys, in this case it really does seem like that most secure method of doing what I want, especially considering all the "/sys/devices/system/cpu/cpu[0-3]/cpufreq/scaling_governor" virtual files control is setting this governor...

I suppose my options come done to either making those /sys entries world writable, or altering an alternative SUID screen locker to do this also (slock from suckless.org looks like a decent choice for that).

The annoying thing here is the fact that the group ownership reset things seems to happen at random, and I have no idea of where it's coming from, I hate this "automagically does stuff for your own good with you knowing" kind of stuff...

----------

## Sadako

Another possibility I just though of, modifying the kernel source...

Just had a quick look, and having the kernel make those files writable rather than readonly to the group would be extremely simple, however changing the group ownership doesn't look so trivial, and that's where the issue is...

May not even be possible, I'm guessing all files under sys are supposed to be owned by root:root (a quick search with find suggests the files I altered myself are the only ones not owned by root:root), and the sysfs code itself periodically resets those, so there may not be any infrastructure there for alternative ownership...

Well, poop goes that idea, I guess.  :Sad: 

----------

