bug#25325: elogind does not set ACLs promptly

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

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 <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