Re: [systemd-devel] logind device access weird behavior

[serenissi]

Right! Stupid me. It just occurred to me that it is debian (which adds local users to video) and `group::---` looks sus. I spun up the vm to confirm and saw this reply in my inbox. Thanks!

~serene

On 4/1/25 19:36, Mantas Mikulėnas wrote:

It sounds as if your original user is in the "video" group, so it receives the 'group' permissions and not 'other' permissions. (They are not additive in the POSIX model like they would be in Windows.)

Use "setfacl -m g::rwx" to change the main group access entry instead.

On Tue, Apr 1, 2025, 17:29 serenissi <sereni...@inventati.org> wrote:

    I noticed a phenomenon about logind managed devices (drm node). I
    have
    two users, localuser and testuser, the former has a session in seat0
    (this is important). I attached drm card1 to new seat `seat1` and set
    777 permission to the dev node /dev/dri/card1. Now the acl looks like

    # file: dev/dri/card1
    # owner: root
    # group: video
    user::rwx
    group::---
    mask::rwx
    other::rwx

    as expected. Now if I do from a localuser shell: sudo -u testuser cat
    /dev/dri/card1, the device opens as expected. However doing so as
    localuser results in permission denied.

    But if I add another acl entry with setfacl -m u:localuser:rw
    /dev/dri/card1, cat /dev/dri/card1 suddenly works as expected. In
    this
    case the acl is

    # file: dev/dri/card1
    # owner: root
    # group: video
    user::rwx
    user:localuser:rw-
    group::---
    mask::rw-
    other::rwx

    here the `other` entry makes the `user:localuser` entry pointless in
    common sense, which is not the case.

    My hunch is ebpf but I couldn't find where this logic is defined in
    systemd tree. Could anyone here help me with that?


    ~ serene

Even though the device node had no specific ACL entries, it still *had* an ACL in general, so the 'group' permission bits no longer affect actual group permissions: they change the overall ACL access mask (and so can limit access for all entries at once, but not grant access). So doing "chmod 777" actually did the equivalent of setting "u::rwx,m::rwx,o::rwx" while the "g::-" entry was left unchanged with no permissions. If you're not owner but are in the 'video' group you therefore get no access.

OpenPGP_0x20257A7131FFF28B.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature