From: ludo@gnu.org (Ludovic Courtès)
To: Chris Marusich <cmmarusich@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Let non-root users use MTP devices (Attempt #2)
Date: Thu, 29 Dec 2016 23:48:00 +0100 [thread overview]
Message-ID: <871swqe4k6.fsf@gnu.org> (raw)
In-Reply-To: <871swrf3cm.fsf@gmail.com> (Chris Marusich's message of "Thu, 29 Dec 2016 02:15:37 -0800")
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?)?
Does “udevadm settle” trigger the ACL change?
Thanks,
Ludo’.
next prev parent reply other threads:[~2016-12-29 22:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-26 0:59 Let non-root users use MTP devices Chris Marusich
2016-12-26 0:59 ` [PATCH 1/2] gnu: libmtp: Grant "audio" group access to device files Chris Marusich
2016-12-26 13:02 ` Ricardo Wurmus
2016-12-28 11:18 ` Chris Marusich
2016-12-29 9:01 ` Let non-root users use MTP devices (Attempt #2) Chris Marusich
2016-12-29 9:01 ` [PATCH 1/2] gnu: elogind: Enable ACL support Chris Marusich
2016-12-29 9:01 ` [PATCH 2/2] services: desktop: Use libmtp udev rules Chris Marusich
2016-12-29 22:37 ` Ludovic Courtès
2016-12-29 23:57 ` Chris Marusich
2016-12-29 10:15 ` Let non-root users use MTP devices (Attempt #2) Chris Marusich
2016-12-29 22:48 ` Ludovic Courtès [this message]
2016-12-30 0:41 ` Chris Marusich
2016-12-29 22:44 ` Ludovic Courtès
2016-12-26 0:59 ` [PATCH 2/2] services: desktop: Use libmtp udev rules Chris Marusich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871swqe4k6.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=cmmarusich@gmail.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).