[arch-general] systemd and local group membership

[Curtis Shimamoto]

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