bug#25325: elogind does not set ACLs promptly

bug#25325: elogind does not set ACLs promptly

[Chris Marusich]

[-- Attachment #1.1: Type: text/plain, Size: 161 bytes --]

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


[-- Attachment #1.2: Type: message/rfc822, Size: 5821 bytes --]

[-- Attachment #1.2.1.1: Type: text/plain, Size: 3823 bytes --]

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.

-- 
Chris

[-- Attachment #1.2.1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 14 bytes --]


-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#25325: elogind does not set ACLs promptly

[zimoun]

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

bug#25325: elogind does not set ACLs promptly

[zimoun]

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

bug#25325: elogind does not set ACLs promptly

[zimoun]

Hi,

On Thu, 03 Feb 2022 at 03:42, zimoun <zimon.toutoune@gmail.com> wrote:
> 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?

Without an answer after a while, I asssume it is not an issue.  So I am
clsoing.  Well, if I am missing a point, feel free to reopen.


Cheers,
simon