From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 01 17:59:08 2017 Received: (at submit) by debbugs.gnu.org; 1 Jan 2017 22:59:08 +0000 Received: from localhost ([127.0.0.1]:38879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNp5n-00057C-Qa for submit@debbugs.gnu.org; Sun, 01 Jan 2017 17:59:08 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNp5l-00056g-Ph for submit@debbugs.gnu.org; Sun, 01 Jan 2017 17:59:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNp5f-0001i9-B4 for submit@debbugs.gnu.org; Sun, 01 Jan 2017 17:59:00 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:51371) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cNp5f-0001i3-70 for submit@debbugs.gnu.org; Sun, 01 Jan 2017 17:58:59 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNp5d-0006lm-Np for bug-guix@gnu.org; Sun, 01 Jan 2017 17:58:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNp5c-0001hc-F2 for bug-guix@gnu.org; Sun, 01 Jan 2017 17:58:57 -0500 Received: from mail-pg0-x233.google.com ([2607:f8b0:400e:c05::233]:36063) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNp5c-0001gF-6S for bug-guix@gnu.org; Sun, 01 Jan 2017 17:58:56 -0500 Received: by mail-pg0-x233.google.com with SMTP id f188so197761191pgc.3 for ; Sun, 01 Jan 2017 14:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:user-agent:mime-version; bh=17LrqkhQiuwW2mEAFEaWSRYmCVW9LlRc9SSeKFl8NhU=; b=fq8sNYnfpPXvPZ2lzV03AyFiS0rXy0uShtoJiCMUh6gHUDkRQbqvNe14EdMlvfkRwP uc0aU8qv7QLbMmIMsq0X7Ky5/bMq4U7J9jCZnUWUT4zht/IvZUVzV5PpiVOO/g89nO8x nFtrl8IuisIJfr/ECt+wHkjsngKayqeRlEBD0y+t96Bk/I13L1ykNG0TcGqdyadXBwGi xX6vsCl8eX0ZU3VFbqzP/A0N++ZwbL6xj2xwx0mEfh2ifMrJpenfgHNYOL/5yHYQ8azl hSqvjTCVn/Aqxzb52LlikqPicEnfIzBAvA/iuDirBih3pf4IfPKwWtJDaj1feiheKUv9 yRnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version; bh=17LrqkhQiuwW2mEAFEaWSRYmCVW9LlRc9SSeKFl8NhU=; b=Laf4ztf0gpq/Aj9/8wPxwa5f9DhVyfADviYsIkxaTciZ4Opoh9XrTfE5v5GvOP+jzd sKjjJ9OzdnWkdJ1qXOX9v/XOIXyVUmB/7hh7dVOzokUeEkYsdWn0aXiBbSMF8xdS35OB VG9try6NZbAtl0gLEV0hC3xc0OH42XUBkQ5M8ExmmiKsXd7DbzyEvvK0RJz30fdq1FE7 uGayoT4m7SN0uX/ILWQpVmn/R+MCJxl4xpFEQ9CmnpNFIplns9EeJyqWsQMhUC1+JWcv KTlRqGx+NdoQqsD8dH/zdBPlsW3shxHSzeuLDMosUgqbAcDWvBwgqbd5temcPHiJf+LG ZDvA== X-Gm-Message-State: AIkVDXLHeOwSdO059EXJEpF4Jf1E6a0YwQHY6dDVfk3qz9vS5VJnqy+7u7mey/zHjbFYkg== X-Received: by 10.84.210.38 with SMTP id z35mr104904113plh.111.1483311534909; Sun, 01 Jan 2017 14:58:54 -0800 (PST) Received: from garuda ([2601:602:9d02:4725:4e0f:6eff:fef6:70b9]) by smtp.gmail.com with ESMTPSA id k5sm62223425pfb.81.2017.01.01.14.58.54 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 01 Jan 2017 14:58:54 -0800 (PST) From: Chris Marusich To: bug-guix@gnu.org Subject: elogind does not set ACLs promptly Date: Sun, 01 Jan 2017 14:58:50 -0800 Message-ID: <87k2aewfo5.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="===-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --===-=-= Content-Type: multipart/mixed; boundary="==-=-=" --==-=-= Content-Type: text/plain 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 --==-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit Return-Path: Received: from garuda ([2601:602:9d02:4725:4e0f:6eff:fef6:70b9]) by smtp.gmail.com with ESMTPSA id y29sm107511230pfd.63.2016.12.29.16.41.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 29 Dec 2016 16:41:14 -0800 (PST) From: Chris Marusich To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Cc: guix-devel@gnu.org Subject: Re: Let non-root users use MTP devices (Attempt #2) References: <87mvfggv4k.fsf@gmail.com> <20161229090121.3718-1-cmmarusich@gmail.com> <871swrf3cm.fsf@gmail.com> <871swqe4k6.fsf@gnu.org> Date: Thu, 29 Dec 2016 16:41:10 -0800 In-Reply-To: <871swqe4k6.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 29 Dec 2016 23:48:00 +0100") Message-ID: <87ful6xn89.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Chris Marusich skribis: > >> Chris Marusich 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=E2=80=99t know. Does this happen only for MTP devi= ces 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 =E2=80=9Cudevadm settle=E2=80=9D 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. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlhlrScACgkQ3UCaFdgi Rp2VJBAAuIPsrckce8S75IeyJWWvcKE0e/sKjb7fpkmMvQyAiJ4XKWwyGK0xuNHn gx+FPH/bIeybaOemJklH4F+TP1O8muCkzhLLPvoP3lrpj7gMuThruzXKVsTYIHYb 2Cm9fE9U4stFNCVlUrrRuFqS9grtrd05Z/2Hwr2DYFNiq45y3Dpdr1mus9NEv3iZ PAMiZB9tE8NSMoGKevo90XLQUDTBaHGuk9UOphWZ7QijCB/dTfNm7IXVbzpffa4u 8XOtsNk3ISimFMx+6P3f/moj27jtmMJnl65ayVgQV7iIKpnlyW7hMJ4gGusRJrV3 xQMxwvlrodYzmd0h9i0j7mhk6YutB9ZIWBkXPvYmIWzIHKh9WFDK+vPiZBctcxP1 5ss5n5DxEKPh6Rv6nQsOcOYUG1EboWhyKWX18iV15cP7+akPdUGifDGYnTStO5R1 Aap3X4yRPF/T9x6JcAtDWwEaRK/ry188tYNPZFyjnKIZxGlxTNqzMiFZvVRTUn3x ZRQXi+MtElqcnSEkpxlJtxfKc+IsQxtsAkh6+NjlSBv7WXhh8ExvEXjCi5x59FqC DRZkK059zoXIGPtxwPlufghRgHaAJmB2SAdPW36YUjO48roi9eE8mLH2JTBb/00z r9YP4/nzasq99l5znSkjFBzhLMd6bZUeM134Y2yZlls/qFuGbWQ= =WczD -----END PGP SIGNATURE----- --=-=-=-- --==-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =2D-=20 Chris --==-=-=-- --===-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlhpiasACgkQ3UCaFdgi Rp1t3BAAlzE6UQy+89IuSrMaNR2a6NI8ZjcnzeIqNPMaG1i61jw0IllAUlJOYoJq 4jcdmQ3z5fj/IPB2vWmkrIXlkV3L7Oa1nJKv44agZmsC/rDINlixA33xE6nlvVwe yZ6fBUTyokebS376DgpwRGs0NZziACVULI7l7fhpsG47nodkWlAzX9FLqF4i/wNY 5HCY0z32BTKzD8w8ZRs06iK4vcuij/oN5B36jwjsHp49WbgQ+Mb0ZpdJZpXkAwpT 8FKqwQ/zOYal8HNE3k56J3Kd/9ooekPElKsqDMxf7Zudv0mTBZr2BgvbgaVrrncR 4TFBlNHLQs6K3lWT5BWtBx3JGdZdzEBRQlo6zxnjdneCrOLc5tF8wcyIks0ZDJ+s ZBDHiDsEbDf3nYnbjbdh3jwWezDQ1XgU5YfleHoUaDBhicpjpUDF5Nde0Bf38Qq9 ag88bxt0TYc/5rgQJuihuAxcsimgVmGB1dNIcqfPh6ffs66Mf0jZvWCGQUVnbP7Q amW2xKSCyx3dzebFyeVCasUEqHdp8e0X+cgPOftoPd7G+s8E4ndHnfNrt2ZwsLbb eknDw9++L/C/n6ukYvcfe9sJu1fSCP7PxvHhGFXkcKKP3foGA6MXkHcPGvBKNWMj xFXU+ax6Yr8X7hb+kNwPtLh6NrQBSL32tFS3hzadYefaerqEU0c= =sucj -----END PGP SIGNATURE----- --===-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 04 18:41:38 2022 Received: (at 25325) by debbugs.gnu.org; 4 Jan 2022 23:41:38 +0000 Received: from localhost ([127.0.0.1]:39136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4tQw-0005Bx-4e for submit@debbugs.gnu.org; Tue, 04 Jan 2022 18:41:38 -0500 Received: from mail-wr1-f43.google.com ([209.85.221.43]:46863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4tQu-0005Bj-IA for 25325@debbugs.gnu.org; Tue, 04 Jan 2022 18:41:37 -0500 Received: by mail-wr1-f43.google.com with SMTP id i22so79242794wrb.13 for <25325@debbugs.gnu.org>; Tue, 04 Jan 2022 15:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=0QUKrGzrzGQWz2/PrEvxjtnRMCpIJLhlnSBSIG7dCZQ=; b=Ie2L+nAnZKIGVsa76iniYdSYQ4WzhoyFbxIE4ANugPxo5ZAxna6u2wuPy1IwuAYIB6 14vYjbzmTRxTwdH1nOk7YYbhWb6KVfE49/z3kDgjLuZVqmYhqE9hZACVfjtsXI/ky8OQ X7NTS1Z/J67ReALiVee6ymKWQVJtttyZmyXprbTbKCn68mUCS6DLhYdak8ovQfMYBCmj taHvKYmjgKYIhs2Vy6Fd6Lev6jLkMkpw3a23Z5ZXJ+dN6EwW0FJKpedjK27ExA4YY2Qa q+SUbx7BQmpWXyQmmPyuH8KJD01ZJ1eFRD0oaKN+P0UH0PX39JJtPovsaXO+M02Bz2c6 Issg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=0QUKrGzrzGQWz2/PrEvxjtnRMCpIJLhlnSBSIG7dCZQ=; b=JAv/XQSp/gv2PH8Bo9xBq2LeAjD6f4H2SXEzVyG71osLN9YcvpBiwkQOMB+Vo+c4MV VL7yJaUimy2uvywXUgccc8X4ChCd3Oe1O5XDrMMRVgh/XL7RdagPcP+M2FtKBJITORFW JR13CcJBQwVcs1A4ma3MyqQGuxBlhBYGvglx0Oxxj+NFlxHnNuK6upMRrw4JN0wiIznX MxgrqC2yEg4QMtJd0Y584timPi7Lzooob9PegeZz9xj6JA+EI4FgBmTqwvbfyoTgsqOv +tBGwsZSJgLPt8VbzwvJAD2WH7eTyS7T0MCbA2NmE23kA7xqrePAWpifTcZTPBEOZDhy D5YA== X-Gm-Message-State: AOAM531VBJWzOvXDAKJH6YieAKNSAnJrbl0vmj8524BEfS988Qg5ATVJ 7heXRfEMb8LPREzGdHZmD+Mki1znO3k= X-Google-Smtp-Source: ABdhPJyJ40lHxPOLqRrHBroDMy73B8QTQVij9c68PtROOPPosRb2FevQJ4B3LFVQ5/9WHB33PUxtUQ== X-Received: by 2002:a5d:64c3:: with SMTP id f3mr43356560wri.295.1641339690711; Tue, 04 Jan 2022 15:41:30 -0800 (PST) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id m17sm898919wms.25.2022.01.04.15.41.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jan 2022 15:41:30 -0800 (PST) From: zimoun To: Chris Marusich Subject: Re: bug#25325: elogind does not set ACLs promptly References: <87k2aewfo5.fsf@gmail.com> Date: Wed, 05 Jan 2022 00:37:58 +0100 In-Reply-To: <87k2aewfo5.fsf@gmail.com> (Chris Marusich's message of "Sun, 01 Jan 2017 14:58:50 -0800") Message-ID: <865yqzax7t.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25325 Cc: 25325@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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: On Sun, 01 Jan 2017 at 14:58, Chris Marusich 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 > Subject: Re: Let non-root users use MTP devices (Attempt #2) > To: ludo@gnu.org (Ludovic Court=C3=A8s) > 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=C3=A8s) writes: > >> Chris Marusich skribis: >> >>> Chris Marusich 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 wh= en >>>> 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 deskto= ps >>>> 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 bei= ng >>>> 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=E2=80=99t know. Does this happen only for MTP dev= ices 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 =E2=80=9Cudevadm settle=E2=80=9D 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 02 21:50:59 2022 Received: (at 25325) by debbugs.gnu.org; 3 Feb 2022 02:50:59 +0000 Received: from localhost ([127.0.0.1]:54072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFSD4-00011W-Vz for submit@debbugs.gnu.org; Wed, 02 Feb 2022 21:50:59 -0500 Received: from mail-wr1-f43.google.com ([209.85.221.43]:36793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFSD2-000112-0q for 25325@debbugs.gnu.org; Wed, 02 Feb 2022 21:50:58 -0500 Received: by mail-wr1-f43.google.com with SMTP id u15so2168570wrt.3 for <25325@debbugs.gnu.org>; Wed, 02 Feb 2022 18:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=vOmDMJl64HD76i0nbQn/KLcHH2VkpZtJhnKoc4TsvyI=; b=MInmNts2ctXj++0LNvgVV+p2pY5rOWMqyVBK+TNJJJJPQG7xxBaUBLjZJkfYJQl7f/ w1046NKjEJdJZ5gG9k+g74ig+YUtKeFoNNN+CAM0BDgB3eWKIA34EEU4m7Jb7LeCWCHj zVRwuxkCJPmX3nkGICrXi4BhGDRsHGDridYym6y/xg+Pl98nQB27XLgQqOMpJDAtc+zB LA8JV6pP09Tm1vQXnCt4lwhUAFukTK1uJk4WFgV9n/gDML022FRv3+T0T4EdZGbPJFn3 LKcf9X2LcLEuQsY0dhWT7j/5efkFfmgzejMytRNWEpgU27VlKVquW3J6uYceSNR2TIY9 ALfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=vOmDMJl64HD76i0nbQn/KLcHH2VkpZtJhnKoc4TsvyI=; b=oc6Id604nb94ZDra4HbZ8le4EmUFXkHNZXtw9DQJvTSww/KeTS/CFlSVxjQmsI+NF/ Qlt/WEr9Mx+xXNo9f5NdNNwOr43zfAGg2jiOeOiIKPHdRNmbxS27nMerneOQOo5JsGav bSJmo3dvL+rXHUJFMkONYTrN6PnlZi/1m7dg6g7t4Jl+7PdZUe1v7bgb8tzGTlHmy82g p5351Svj4ErP93/b/TX+TUnSXyiOHljO65Ko7BYl40OjdK+WzgupyWXd2TEX/9IgN7t3 6y+kJUAs7PDsJJ2P51XRqOmzXdK5KQ1NE8LyD6AWf1v4/XPadWTUHeyKqRAeJQt0JQfe IrAw== X-Gm-Message-State: AOAM531KaeQpG7kQklthKYM4Na9ARzES4PQM9O11Cf07fbaKmNQtOicC yVf1OsQYG3i3exq3PmDWixUJDkdVVI0= X-Google-Smtp-Source: ABdhPJx0E4MrFRpMvygkiB2NyTXcExBYASU6XvE86uq0WtY+hRHEwqlqtFzOjtvy2Qz0HSjWfc75hg== X-Received: by 2002:a5d:5589:: with SMTP id i9mr28096890wrv.316.1643856650144; Wed, 02 Feb 2022 18:50:50 -0800 (PST) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id f13sm18551009wrp.105.2022.02.02.18.50.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Feb 2022 18:50:49 -0800 (PST) From: zimoun To: Chris Marusich Subject: Re: bug#25325: elogind does not set ACLs promptly References: <87k2aewfo5.fsf@gmail.com> <865yqzax7t.fsf@gmail.com> Date: Thu, 03 Feb 2022 03:42:38 +0100 In-Reply-To: <865yqzax7t.fsf@gmail.com> (zimoun's message of "Wed, 05 Jan 2022 00:37:58 +0100") Message-ID: <86a6f81xi9.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25325 Cc: 25325@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, On Wed, 05 Jan 2022 at 00:37, zimoun 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: Can I assume it is not an issue anymore? > On Sun, 01 Jan 2017 at 14:58, Chris Marusich 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 >> Subject: Re: Let non-root users use MTP devices (Attempt #2) >> To: ludo@gnu.org (Ludovic Court=C3=A8s) >> 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=C3=A8s) writes: >> >>> Chris Marusich skribis: >>> >>>> Chris Marusich writes: >>>> >>>>> Here's a second attempt to fix MTP support for GuixSD. It's simple a= nd >>>>> 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 w= hen >>>>> 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 deskt= ops >>>>> 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 attach= ed >>>>> to their seat. For instance, after this change, I can access /dev/kvm >>>>> and /dev/cdrom (and other devices) without being root, and without be= ing >>>>> 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 assum= ed >>>> 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 u= p, >>>> 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 ACL= s, >>>> 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=E2=80=99t know. Does this happen only for MTP de= vices 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 =E2=80=9Cudevadm settle=E2=80=9D 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 23 06:41:53 2022 Received: (at 25325-done) by debbugs.gnu.org; 23 Mar 2022 10:41:53 +0000 Received: from localhost ([127.0.0.1]:42841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nWyR6-0007OQ-MK for submit@debbugs.gnu.org; Wed, 23 Mar 2022 06:41:52 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:35404) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nWyR4-0007O4-Nw for 25325-done@debbugs.gnu.org; Wed, 23 Mar 2022 06:41:51 -0400 Received: by mail-wr1-f41.google.com with SMTP id v22so1491753wra.2 for <25325-done@debbugs.gnu.org>; Wed, 23 Mar 2022 03:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=F4E+Wv2XFh1wvvxvV+htqoq2zunMU/hTkjxv/qfjbzg=; b=Jyon0KvLRL8kd9Y1pknP02vOCNKGiO+OR6P9ct67TPwD4N7IpnCVarA1frApaC9E3f EWE/Vsm8ErWFHmbHZPN4KjOi7XVqUJm1u3eEcgWEo8oKBu+Gs4BBa8Z9mExD5Kat14Pm TP9IELNI2jLKOWSxI/9TbmybznY1tzFWS2r3JoW/UWd7kmD+/Ecsdx/GZbx5YU275dCt uaE8IKrT82Tic23nH0s8zTHm8GssvYSxu1A3obk3TqJ1VtspwOlYkQYc7BfphsJjmb5w lp5S7JTuw8K23q6pulb8rBFuQVgbUmbZEUwTq3wNi6C37vrw+Wm7TiTrGHZDOo3KGkYP dPdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=F4E+Wv2XFh1wvvxvV+htqoq2zunMU/hTkjxv/qfjbzg=; b=2CqgGaqhJcgthmtu+lBmoCtuV7YlYmgeq+KACnCyjTIfmxOpw2Fw8R51wZEDf6F5T3 Oy33TUhQIx15E86UIsObicjqKGBzpCOl+lpqW7CgLRMZWbQp9cT9pEuX+PSUzeD17klg J2BZLWYasH6F9jvV59Y7qxtzRXi8w1ePVVaOVtTAAhp8kb1lxedkmymvJ86eRkVsCQO4 AOALd/zrQHu1e3dkuxP/GTR3z/Y18d9m1Pf1AfX8/j9Gbx9I8Q2xFrZWJSwlWFKOwD3w XP7dSJ+DG/5zccHczJGXQtAK7uRgR6RrHCyGrKinYJqgV8i4Hn4kBf5cKoKsIrv/D+Fo Manw== X-Gm-Message-State: AOAM532qVotmSy1C5HguRfyvXwlKwwW0h5QqAm49DgyI7JQTm9S7kxBO IOzMsjt2SPtT8BC5wp9UV3GWLBMP+fK33Q== X-Google-Smtp-Source: ABdhPJxtDUyWDDwLo9v49scaV7iXBGSrhLZLdbIrrQ+0ZYanNwSlhN3v4qZun7wZk09HQ9LH5BVYqQ== X-Received: by 2002:a05:6000:2a6:b0:203:ebe1:2900 with SMTP id l6-20020a05600002a600b00203ebe12900mr24301513wry.423.1648032104929; Wed, 23 Mar 2022 03:41:44 -0700 (PDT) Received: from lili (client-eduroam632.canalip.upmc.fr. [134.157.122.122]) by smtp.gmail.com with ESMTPSA id b15-20020a05600018af00b002057c72d45fsm3907455wri.77.2022.03.23.03.41.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 03:41:44 -0700 (PDT) From: zimoun To: Chris Marusich Subject: Re: bug#25325: elogind does not set ACLs promptly References: <87k2aewfo5.fsf@gmail.com> <865yqzax7t.fsf@gmail.com> <86a6f81xi9.fsf@gmail.com> Date: Wed, 23 Mar 2022 11:39:11 +0100 In-Reply-To: <86a6f81xi9.fsf@gmail.com> (zimoun's message of "Thu, 03 Feb 2022 03:42:38 +0100") Message-ID: <86r16t0x80.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25325-done Cc: 25325-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, On Thu, 03 Feb 2022 at 03:42, zimoun wrote: > On Wed, 05 Jan 2022 at 00:37, zimoun 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: > > 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 From unknown Sat Jun 14 05:11:25 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 20 Apr 2022 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator