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>
