[systemd-devel] Fwd: creating dynamic access control lists for a device: systemd and udev

[Ian Malone]

On 25 March 2012 19:50, Kay Sievers <kay at vrfy.org> wrote:
> On Sun, Mar 25, 2012 at 20:31, Ian Malone <ibmalone at gmail.com> wrote:
>> Hi, I've posted this to the Fedora developers list, but maybe it's
>> more appropriate here. Since writing it I've confirmed the uaccess TAG
>> does what I expect, but I'm not sure having that set directly by the
>> device rule would be approved in a package to include in Fedora.
>
> Ideally nothing should directly 'execute the policy' by setting the
> 'uaccess' tag for systemd.
>

Thanks, that's what I'd thought.

> It should be indirectly set by using a variable that classifies a
> certain device class which administrators might want to grant or not
> grant access to logged-in users. Currently all variables recognized in
> the uaccess rules file set the tag, but that could change in the
> future, whenever some more fine-grained policy might be needed.
>
> Current generic device classes are:
>  ID_CDROM
>  ID_SMARTCARD_READER
>  ID_FFADO
>  ID_PDA
>  ID_REMOTE_CONTROL
>  ID_MEDIA_PLAYER
>

So these are the ones recognised by the uaccess file, but I wasn't
sure if there were any restrictions. This namespace seems to be shared
by things like ID_SEAT and ID_USB_INTERFACES which I suspect should be
left alone.

> Just invent some useful generic name for the type of device. :) And we
> can add that to the uaccess rules.
>

Was finding it a bit tricky to think of a generic name, most devices
like this would be controlled by midi instead (and therefore already
handled as sound I think). If that's not a potential source of
conflict then ID_AMPLIFIER (though that might suggest a USB audio
device), ID_AMPLIFIER_PANEL or ID_EFFECTS_BOX might do. It basically
presents a set of knobs which can be tweaked via USB-HID. So if the
midi thing might be an issue then maybe ID_USB_ROBOT? I have no
particular opinion on the subject, whatever you think would fit in
best with the existing arrangements.

What would the best strategy be for device rules provided prior to the
addition of this to the uaccess rules? Is it acceptable for a
separately distributed device file to provide its own equivalent of
'ENV{ID_REMOTE_CONTROL}=="1", TAG+="uaccess"' to be removed at a later
date, or would it have to be added by a user as a site-rule under
/etc?

Thanks for your time.
-- 
imalone