On 10/29/12 at 12:00am, Tom Gundersen wrote: > On Sun, Oct 28, 2012 at 7:09 PM, Fons Adriaensen <fons@xxxxxxxxxxxxxx> 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@xxxxxxxxx
