bug#25325: elogind does not set ACLs promptly

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Wed, 05 Jan 2022 at 00:37, zimoun <zimon.toutoune@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 <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.

Cheers,
simon