On 10/29/12 at 12:00am, Tom Gundersen wrote:
On Sun, Oct 28, 2012 at 7:09 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
You (Tom) pointed out a way to disable logind modifying device ACLs recently. It could be a good thing to have that in the online docs for those users (like me) for whom this sort of thing is unwanted.
The rule that tags device nodes with the "uaccess" tag (which means they will be managed with ACL's) is 70-uaccess.rules[0]. A brute-force way to avoid all of that is to "mask" it. I.e., symlink /etc/udev/rules.d/70-uaccess.rules to /dev/null.
In most cases that's not the best solution, as you lose all the fast-user switching and multi-seat stuff, but it is useful to know.
Hopefully the logind manpage will be updated soon to include a bit more info on these things.
Logind's behaviour seems to be based on two assumptions:
1. A non-local user (not near the system's HW) can't do anything useful with e.g. audio interfaces.
Not really. Logind does not at all manage non-local users, so if you want to give them access to your hardware you have to use another mechanism (such as groups).
2. A local user (having access to the system's HW) can do whatever evil he wants so there's no point in taking away any permissions.
Not really. This is indeed the default behaviour, but it is set up so that you can easily restrict it (and you should if you have a multi-seat computer): a user is given all the permissions to the hardware (as specified in 70-uacces.rules) on his/her seat. By default all hardware is assigned to seat0 and the user is assigned to seat0 too, but you could easily assign some hardware to a different seat.
For (2), a local user can do whatever evil only if he has unlimited time and is not supervised. I routinely let clients login to the local machines in the studio (they have to in order to do their work). That doesn't mean they should be able to copy other customer's data when I'm out for a minute to get us a coffee. So they must not be able to mount USB disks etc.
logind does not allow mounting of USB disks, but your point still stands (udisks would probably allow it based on info from logind, or you could get the same sort of effect using a device that logind would allow you to access).
-t
[0]: <http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules>
I have been following this thread extra closely since I had removed myself from the numerous unnecessary groups, yet didn't quite understand why. Looking over 70-uaccess.rules, it is all making sense now. I did run into one problem though. I sometimes use mplayer from the console. To do this, I have set mplayer up to use fbdev2. Previously (when in all those groups), I was able to do this with no problem. but after making these changes, I suddenly had to be root to use mplayer in framebuffer mode. I realized that this was because /dev/fb0 was not included in the 70-uaccess.rules. I am no expert in udev rules, but I have written a few for various things. This file was dead simple to understand, so I copied it over to /etc/udev/rules.d and added: # framebuffer SUBSYSTEM=="graphics", KERNEL=="fb0", TAG+="uaccess" So I guess I just want to know if this is what I was supposed to have done. Or are there reasons why this may not have been implemented in the first place? As far as I can tell, this seems no different than previously being in the video group. If this is not a good idea, why might this be? Any insight would be greatly appreciated. Regards, -- Curtis Shimamoto sugar.and.scruffy@gmail.com