Toggle quote (85 lines)
> On Sun, 01 Jan 2017 at 14:58, Chris Marusich <cmmarusich@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 <cmmarusich@gmail.com>
>> Subject: Re: Let non-root users use MTP devices (Attempt #2)
>> To: ludo@gnu.org (Ludovic Courtès)
>> Cc: guix-devel@gnu.org
>> Date: Thu, 29 Dec 2016 16:41:10 -0800 (5 years, 5 days, 16 hours ago)
>>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Chris Marusich <cmmarusich@gmail.com> skribis:
>>>
>>>> Chris Marusich <cmmarusich@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.
