Hi, On Wed, 05 Jan 2022 at 00:37, zimoun <zimon.touto...@gmail.com> wrote:
> 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> Can I assume it is not an issue anymore? > On Sun, 01 Jan 2017 at 14:58, Chris Marusich <cmmarus...@gmail.com> 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 <cmmarus...@gmail.com> >> Subject: Re: Let non-root users use MTP devices (Attempt #2) >> To: l...@gnu.org (Ludovic Courtès) >> Cc: guix-de...@gnu.org >> Date: Thu, 29 Dec 2016 16:41:10 -0800 (5 years, 5 days, 16 hours ago) >> >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Chris Marusich <cmmarus...@gmail.com> skribis: >>> >>>> Chris Marusich <cmmarus...@gmail.com> 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
