Hi Chris, I am doing some triage of old bug and I hit this one [1]. Since it is from 2017 and many things changed since then, is it still an issue?
1: <http://issues.guix.gnu.org/issue/25325> On Sun, 01 Jan 2017 at 14:58, Chris Marusich <[email protected]> wrote: > Please find attached a description of the bug, which came from the > following email thread: > > https://lists.gnu.org/archive/html/guix-devel/2016-12/msg01126.html > > From: Chris Marusich <[email protected]> > Subject: Re: Let non-root users use MTP devices (Attempt #2) > To: [email protected] (Ludovic Courtès) > Cc: [email protected] > Date: Thu, 29 Dec 2016 16:41:10 -0800 (5 years, 5 days, 16 hours ago) > > [email protected] (Ludovic Courtès) writes: > >> Chris Marusich <[email protected]> skribis: >> >>> Chris Marusich <[email protected]> writes: >>> >>>> Here's a second attempt to fix MTP support for GuixSD. It's simple and >>>> requires no special group permissions. >>>> >>>> It turns out that elogind (like systemd's logind) can be compiled with >>>> support for ACLs (provided by libacl), in which case elogind will >>>> automatically set an ACL on a device file granting access to a user when >>>> that user is logged in using a seat to which the device is attached. In >>>> short, by adding acl as an input to elogind, users will be able to >>>> access devices without running programs as root, and without being a >>>> member of any special group. >>>> >>>> That's just one piece of the puzzle, though. The other piece is the >>>> udev rules provided by libmtp. It's necessary to install those udev >>>> rules; if we don't, then the MTP device won't be tagged properly, so >>>> elogind will not set any ACLs for it. I've chosen to install those >>>> rules by modifying the base services in desktop.scm so that all desktops >>>> will get the rules, not just GNOME; if you know of a better way to >>>> install them, please let me know. >>>> >>>> This patch has a happy side effect. Namely: because elogind is now >>>> setting ACLs, it gives a user access to other devices that are attached >>>> to their seat. For instance, after this change, I can access /dev/kvm >>>> and /dev/cdrom (and other devices) without being root, and without being >>>> in any special group. How nice! >>> >>> After sending this, I've noticed something odd: sometimes, it can take >>> quite a while for elogind to set the ACLs. It's a bit of a mystery to >>> me. I'm not sure how/when elogind decides to update the ACLs; I assumed >>> it was continuously checking for changes in the hardware or receiving >>> notifications about hardware changes, but it seems like elogind isn't >>> noticing when I plug in my phone. Even though the device file shows up, >>> elogind doesn't set the ACLs unless I do something. >>> >>> By "do something," I mean: Apparently, logging out and logging back in >>> seems to trigger elogind to set the ACLs. Even just switching virtual >>> terminals (i.e., Control + F1, followed by Control + F7) seems to >>> trigger it, which is weird. Even when elogind has not yet set the ACLs, >>> the "uaccess" tag has in fact been correctly set for the device (as >>> reported by e.g. "udevadm info /dev/libmtp-1-1"), which leads me to >>> suspect that elogind is either failing to notice or just ignoring the >>> hardware change. I wonder if this might be a bug of some kind. >>> >>> What do you think we should do? >> >> Good question! I don’t know. Does this happen only for MTP devices or >> also with other things (KVM?)? > > Yes, this happens for other devices, too. For example, I observe > exactly the same behavior for /dev/sr0 when I plug in an external CD-ROM > drive (via USB cable) after logging in. The ACL doesn't get set until > after I do something like switch to another virtual terminal and back. > >> Does “udevadm settle” trigger the ACL change? > > No, neither "udevadm settle" nor "sudo udevadm settle" triggers the ACL > change. I suspect that maybe elogind is ignoring or failing to notice > the new device, or perhaps the mechanism that elogind relies on to learn > about new devices is not working for some reason. > > It looks like elogind sets the ACLs via devnode_acl_all, defined in > src/login/logind-acl.c. Ultimately it seems this gets called while in > seat_set_active (specifically, invoked at src/login/logind-seat.c:213), > under certain conditions. That's as far as I got. > > I cannot reproduce this issue on Ubuntu; there, the ACL gets set > promptly. Cheers, simon
