creating dynamic access control lists for a device: systemd and udev

[Ian Malone]

On 27 March 2012 19:00, Adam Williamson <awilliam at redhat.com> wrote:
> On Sun, 2012-03-25 at 13:22 +0100, Ian Malone wrote:
>
>> Or indeed, if anyone can show me where this is documented. All I've
>> managed to find with google are git commits and irrelevant mailing
>> list fragments. systemd-logind isn't documented,
>> /lib/udev/rules.d/70-uaccess.rules appears to deal with this, but what
>> I've seen so far appears to say that udev handling of this is being
>> deprecated for systemd,
>
> 70-uaccess.rules is in fact owned by systemd. This is the systemd
> handling of it.
>

Interesting, not sure how you'd tell that. I've now noticed the header
#  This file is part of systemd.
And rpm -qf confirms that, but why don't systemd and udev get into
conflict over it?

>> also there are no suitable ID_ in there, which
>> brings me back to the question of choosing suitable names. Is there a
>> list of reserved names or naming rules? If you were creating
>> site-specific rules presumably they could go in /etc/... To have the
>> package for the software add its own rules would Fedora accept a new
>> ID_ into wherever ID_ needs to go? (70-uaccess.rules?).
>
> That is what you need, yes. AIUI, anyway. My experience with this is in
> the context of libconcord, which handles Harmony remote controls; Kay
> got ID_REMOTE_CONTROL added to udev (at the time) and 70-uaccess.rules
> owned by systemd (now) for libconcord to use in its udev rules file.
>

Thanks for that. I'd run some discussion of the ID_REMOTE_CONTROL
property and it did look like the most relevant situation. Nice to
have some confirmation.

>> I assume that
>> setting TAG+="uaccess" directly (assuming that's what's needed, is it?
>> how should I know?) in a device rule would be frowned on.
>
> I believe so, yeah. The idea is to handle categories of device together
> so that admins can more easily customize the behaviour, I think.

Yes, Kay has confirmed this on the systemd devel list.

-- 
imalone