Hi,
I put in a RFE https://bugzilla.redhat.com/show_bug.cgi?id=806534 for a udev rule for the Fender Mustang amplifier and got a very quick response from Kay Sievers (some needs to tell RedHat about weekends). Obviously things have moved on since I last looked at permissions and their use with devices. Anyway his answer was this:
--- Systemd/udev offers to assign dynamic access control lists to device nodes, which are only added when the user's login is active/in the foreground. For that to work, a name ID_<some name> for the device class needs to be found, this property needs to be set by the rules, then added to the systemd file, and logged-in users with active session will get access the the device.
The rules file can be a single line like: SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", \ ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="000[456]" \ ENV{ID_<some_name>}="1" ---
The matching shown is for the device, what I don't know is how to choose the ID_<some_name> to set; whether there are existing ones that might be appropriate or whether I need to create a unit in systemd and a new ID_ for it. The software that needs this is currently packaged by someone as RPM for SUSE and Fedora, but I'd hope it could eventually be moved into Fedora and getting these rules right would be a step towards that.
Thanks for your time.
On 24 March 2012 19:01, Ian Malone ibmalone@gmail.com wrote:
Hi,
I put in a RFE https://bugzilla.redhat.com/show_bug.cgi?id=806534 for a udev rule for the Fender Mustang amplifier and got a very quick response from Kay Sievers (some needs to tell RedHat about weekends). Obviously things have moved on since I last looked at permissions and their use with devices. Anyway his answer was this:
Systemd/udev offers to assign dynamic access control lists to device nodes, which are only added when the user's login is active/in the foreground. For that to work, a name ID_<some name> for the device class needs to be found, this property needs to be set by the rules, then added to the systemd file, and logged-in users with active session will get access the the device.
The rules file can be a single line like: SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", \ ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="000[456]" \ ENV{ID_<some_name>}="1"
The matching shown is for the device, what I don't know is how to choose the ID_<some_name> to set; whether there are existing ones that might be appropriate or whether I need to create a unit in systemd and a new ID_ for it. The software that needs this is currently packaged by someone as RPM for SUSE and Fedora, but I'd hope it could eventually be moved into Fedora and getting these rules right would be a step towards that.
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, 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?). 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.
On 25 March 2012 13:22, Ian Malone ibmalone@gmail.com wrote:
On 24 March 2012 19:01, Ian Malone ibmalone@gmail.com wrote:
Hi,
I put in a RFE https://bugzilla.redhat.com/show_bug.cgi?id=806534 for
<snip> Taken to systemd-devel.
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.
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.
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.
On 27 March 2012 19:00, Adam Williamson awilliam@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.
Ian Malone wrote:
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?
Because udev dropped their equivalent 70-acl.rules in favor of systemd's implementation.
Kevin Kofler
On 30 March 2012 22:41, Kevin Kofler kevin.kofler@chello.at wrote:
Ian Malone wrote:
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?
Because udev dropped their equivalent 70-acl.rules in favor of systemd's implementation.
No, what I mean is given its location how does udev ignore it and systemd know to find it? I assume it's something to do with 'ACTION=="remove", GOTO="uaccess_end"' at the start.
Ian Malone wrote:
No, what I mean is given its location how does udev ignore it and systemd know to find it?
That's not what happens. Those are udev rules, they're installed by the systemd package, but processed by udev (which sticks a "uaccess" tag on the device, which is later used by systemd to grant ACLs).
Kevin Kofler
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Ian Malone -
Kevin Kofler