<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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!<br>
    </p>
    <p>~serene<br>
    </p>
    <div class="moz-cite-prefix">On 4/1/25 19:36, Mantas Mikulėnas
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPWNY8W3w2AaeFXEo-VKRj8M31_FcZpi70XbKGuJGrfSwNrU6Q@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">
        <div>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.)</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">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).</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">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.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Use "setfacl -m g::rwx" to change the main group
          access entry instead.</div>
      </div>
      <br>
      <div class="gmail_quote gmail_quote_container">
        <div dir="ltr" class="gmail_attr">On Tue, Apr 1, 2025, 17:29
          serenissi <<a href="mailto:serenissi@inventati.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">serenissi@inventati.org</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I
          noticed a phenomenon about logind managed devices (drm node).
          I have <br>
          two users, localuser and testuser, the former has a session in
          seat0 <br>
          (this is important). I attached drm card1 to new seat `seat1`
          and set <br>
          777 permission to the dev node /dev/dri/card1. Now the acl
          looks like<br>
          <br>
          # file: dev/dri/card1<br>
          # owner: root<br>
          # group: video<br>
          user::rwx<br>
          group::---<br>
          mask::rwx<br>
          other::rwx<br>
          <br>
          as expected. Now if I do from a localuser shell: sudo -u
          testuser cat <br>
          /dev/dri/card1, the device opens as expected. However doing so
          as <br>
          localuser results in permission denied.<br>
          <br>
          But if I add another acl entry with setfacl -m u:localuser:rw
          <br>
          /dev/dri/card1, cat /dev/dri/card1 suddenly works as expected.
          In this <br>
          case the acl is<br>
          <br>
          # file: dev/dri/card1<br>
          # owner: root<br>
          # group: video<br>
          user::rwx<br>
          user:localuser:rw-<br>
          group::---<br>
          mask::rw-<br>
          other::rwx<br>
          <br>
          here the `other` entry makes the `user:localuser` entry
          pointless in <br>
          common sense, which is not the case.<br>
          <br>
          My hunch is ebpf but I couldn't find where this logic is
          defined in <br>
          systemd tree. Could anyone here help me with that?<br>
          <br>
          <br>
          ~ serene<br>
          <br>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>