Let non-root users use MTP devices

Let non-root users use MTP devices

[Chris Marusich]

These small patches enable easier MTP file transfer for devices, such as
Android phones, on GuixSD.

Previously, you had to run a program as root (e.g., "sudo gmtp") to do this,
and the MTP backend for gvfs was not functioning properly (i.e., you could not
use a program like Nautilus to transfer files).  This was because we were
missing some udev rules that the libmtp package provides.  These patches add
those rules and configure libmtp so that the rules will grant the "audio"
group access to the MTP-related device files.  After these patches are
applied, any user in the "audio" group will be able to use tools like "gmtp"
without running them as root, and the MTP backend for gvfs will "just work"
for any user who is in the "audio" group.  I've verified that this works in
GNOME and also Xfce; I was successful in transferring files to an Android
device using drag-and-drop via Nautilus.

Note that in order to use a program like "gmtp," you'll probably need to make
sure no other programs (e.g., "gvfs-mtp-volume-monitor") are using the device
at the same time.  Apparently, when using MTP, only one process can use a
device at a time.  For details, please refer to the documentation in the
libmtp source.

-- 
Chris

[PATCH 1/2] gnu: libmtp: Grant "audio" group access to device files.

[Chris Marusich]

* gnu/packages/libusb.scm (libmtp): Set udev group to "audio".
---
 gnu/packages/libusb.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/libusb.scm b/gnu/packages/libusb.scm
index 215cecee1..f07381646 100644
--- a/gnu/packages/libusb.scm
+++ b/gnu/packages/libusb.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2015, 2016 Ricardo Wurmus <rekado@elephly.net>
 ;;; Copyright © 2016 Efraim Flashner <efraim@flashner.co.il>
 ;;; Copyright © 2016 Theodoros Foradis <theodoros.for@openmailbox.org>
+;;; Copyright © 2016 Chris Marusich <cmmarusich@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -155,7 +156,8 @@ version of libusb to run with newer libusb.")
      `(#:configure-flags
        (list (string-append "--with-udev="
                             (assoc-ref %outputs "out")
-                            "/lib/udev"))))
+                            "/lib/udev")
+             "--with-udev-group=audio")))
     (home-page "http://libmtp.sourceforge.net/")
     (synopsis "Library implementing the Media Transfer Protocol")
     (description "Libmtp implements an MTP (Media Transfer Protocol)
-- 
2.11.0

[PATCH 2/2] services: desktop: Use libmtp udev rules.

[Chris Marusich]

* gnu/services/desktop.scm (%modified-base-services): New variable.
  (%desktop-services): Use it.
---
 gnu/services/desktop.scm | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm
index 7555780ad..72f35950b 100644
--- a/gnu/services/desktop.scm
+++ b/gnu/services/desktop.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2015 Andy Wingo <wingo@igalia.com>
 ;;; Copyright © 2015 Mark H Weaver <mhw@netris.org>
 ;;; Copyright © 2016 Sou Bunnbu <iyzsong@gmail.com>
+;;; Copyright © 2016 Chris Marusich <cmmarusich@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -40,6 +41,7 @@
   #:use-module (gnu packages xdisorg)
   #:use-module (gnu packages suckless)
   #:use-module (gnu packages linux)
+  #:use-module (gnu packages libusb)
   #:use-module (guix records)
   #:use-module (guix packages)
   #:use-module (guix store)
@@ -745,6 +747,16 @@ with the administrator's password."
 ;;; The default set of desktop services.
 ;;;
 
+(define %modified-base-services
+  (modify-services %base-services
+    ;; Add the rules from libmtp.
+    (udev-service-type config =>
+                       (udev-configuration
+                        (inherit config)
+                        (rules
+                         (cons* libmtp
+                                (udev-configuration-rules config)))))))
+
 (define %desktop-services
   ;; List of services typically useful for a "desktop" use case.
   (cons* (slim-service)
@@ -766,6 +778,6 @@ with the administrator's password."
 
          (ntp-service)
 
-         %base-services))
+         %modified-base-services))
 
 ;;; desktop.scm ends here
-- 
2.11.0

Re: [PATCH 1/2] gnu: libmtp: Grant "audio" group access to device files.

[Ricardo Wurmus]

Chris Marusich <cmmarusich@gmail.com> writes:

> * gnu/packages/libusb.scm (libmtp): Set udev group to "audio".
> ---

I just checked how it’s done on Debian and Fedora.  Neither pass this
configuration flag.  On a Fedora system I can access I see that the udev
rules that come with libmtp do not specify any group or mode.

This doesn’t mean that we should not do this, but it’s suspicious.
Maybe there’s something else we’re overlooking here?

I also think that using the “audio” group would be wrong.  This is for
MTP devices, so maybe it would be better to add an “mtp” group.

https://gmtp.sourceforge.io/usage.html says this about root:

    Q. Do I need root access to use gMTP?
    A. […] On Linux, in general No, as libmtp should have set your udev
       rules correctly for libmtp known devices.

And since neither Fedora nor Debian configures libmtp such that the
devices are owned by a particular group, I wonder if maybe that’s not
actually necessary.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: [PATCH 1/2] gnu: libmtp: Grant "audio" group access to device files.

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 4014 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> * gnu/packages/libusb.scm (libmtp): Set udev group to "audio".
>> ---
>
> I just checked how it’s done on Debian and Fedora.  Neither pass this
> configuration flag.  On a Fedora system I can access I see that the udev
> rules that come with libmtp do not specify any group or mode.
>
> This doesn’t mean that we should not do this, but it’s suspicious.
> Maybe there’s something else we’re overlooking here?

This is a good question.  The answer seems to be a little complicated.

I did some testing with a fresh install of Ubuntu 16.04.1 LTS.  I tried
transferring files via MTP between this Ubuntu system and an Android
device, and it "just worked".  On that system, I noticed that the udev
rules installed by the "libmtp-common" package do in fact set the group
to "audio".  The curious things is: the MTP file transfer "just worked"
even though though my test user was not a member of the "audio" group.
Why did it work?  Well, it turns out that the access to the device file
in question was ACTUALLY being granted via an ACL which provided the
necessary access to my test user specifically.  The "audio" group
ownership was apparently superfluous; I don't know why they set it.

So, presumably, MTP "just works" on Ubuntu not because they've made the
"audio" group the owner of the device file (although they have in fact
done that, too); rather, MTP "just works" because something is
automatically setting the ACL for the device file to grant my test user
the necessary access.  Apparently, this is some kind of feature of udev
or systemd or something.  It seems to have something to do with the
"uaccess" rules which are provided by systemd's udev.  It seems (and
this is just my guess, so I might be wrong) like the udev rules from
"libmtp-common" set an environment variable named "ID_MEDIA_PLAYER" to
the value "1", and then in a later udev rules file (called
"70-uaccess.rules", which is provided by systemd), any device for which
this environment variable (ID_MEDIA_PLAYER) has been set also gets
tagged with the magic value "uaccess."  Presumably, something somewhere
in udev will "do the right thing" for these "uaccess"-tagged devices and
set the ACLs up correctly when this tag is present.  I didn't go down
the rabbit hole that far, though, so I can't really say for certain.

All I know is: Ubuntu does in fact set the group owner in their udev
rules file from the "libmtp-common" package, but the actual access
appears to be granted not via group permissions but rather via an ACL
that seems to be granted via this "uaccess" mechanism.

Does this ring a bell?  Do we use ACLs in GuixSD?  Does our elogind
support this "uaccess" magic, too?  If so, then I imagine we might not
need to set the group owner at all.  But if not, then setting the group
owner seems like a reasonable workaround until we can do better.

> I also think that using the “audio” group would be wrong.  This is for
> MTP devices, so maybe it would be better to add an “mtp” group.

Sure, IMO the "mtp" group would make more sense, since as you point out
MTP is not just for audio.

> https://gmtp.sourceforge.io/usage.html says this about root:
>
>     Q. Do I need root access to use gMTP?
>     A. […] On Linux, in general No, as libmtp should have set your udev
>        rules correctly for libmtp known devices.
>
> And since neither Fedora nor Debian configures libmtp such that the
> devices are owned by a particular group, I wonder if maybe that’s not
> actually necessary.

I wonder if Fedora and Debian are using ACLs, too.  Can you confirm
that?  You can check using "ls -l" (look for the "+" near the file
mode), or by running "getfacl" on the device file (i.e., whatever device
file is pointed to by the /dev/libmtp-2-1 symlink or similar).

I just wanted to put music on my phone, that's all!! :-)

-- 
Chris

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

Let non-root users use MTP devices (Attempt #2)

[Chris Marusich]

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!

-- 
Chris

[PATCH 1/2] gnu: elogind: Enable ACL support.

[Chris Marusich]

* gnu/packages/freedesktop.scm (elogind) [inputs]: Add acl.
---
 gnu/packages/freedesktop.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/freedesktop.scm b/gnu/packages/freedesktop.scm
index 37707796e..ddbac762a 100644
--- a/gnu/packages/freedesktop.scm
+++ b/gnu/packages/freedesktop.scm
@@ -211,7 +211,8 @@ the freedesktop.org XDG Base Directory specification.")
        ("shepherd" ,shepherd)                ;for 'halt' and 'reboot', invoked
                                              ;when pressing the power button
        ("dbus" ,dbus)
-       ("eudev" ,eudev)))
+       ("eudev" ,eudev)
+       ("acl" ,acl)))
     (home-page "https://github.com/wingo/elogind")
     (synopsis "User, seat, and session management service")
     (description "Elogind is the systemd project's \"logind\" service,
-- 
2.11.0

[PATCH 2/2] services: desktop: Use libmtp udev rules.

[Chris Marusich]

* gnu/services/desktop.scm (%modified-base-services): New variable.
  (%desktop-services): Use it.
---
 gnu/services/desktop.scm | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm
index 7555780ad..72f35950b 100644
--- a/gnu/services/desktop.scm
+++ b/gnu/services/desktop.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2015 Andy Wingo <wingo@igalia.com>
 ;;; Copyright © 2015 Mark H Weaver <mhw@netris.org>
 ;;; Copyright © 2016 Sou Bunnbu <iyzsong@gmail.com>
+;;; Copyright © 2016 Chris Marusich <cmmarusich@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -40,6 +41,7 @@
   #:use-module (gnu packages xdisorg)
   #:use-module (gnu packages suckless)
   #:use-module (gnu packages linux)
+  #:use-module (gnu packages libusb)
   #:use-module (guix records)
   #:use-module (guix packages)
   #:use-module (guix store)
@@ -745,6 +747,16 @@ with the administrator's password."
 ;;; The default set of desktop services.
 ;;;
 
+(define %modified-base-services
+  (modify-services %base-services
+    ;; Add the rules from libmtp.
+    (udev-service-type config =>
+                       (udev-configuration
+                        (inherit config)
+                        (rules
+                         (cons* libmtp
+                                (udev-configuration-rules config)))))))
+
 (define %desktop-services
   ;; List of services typically useful for a "desktop" use case.
   (cons* (slim-service)
@@ -766,6 +778,6 @@ with the administrator's password."
 
          (ntp-service)
 
-         %base-services))
+         %modified-base-services))
 
 ;;; desktop.scm ends here
-- 
2.11.0

Re: Let non-root users use MTP devices (Attempt #2)

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]

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?

-- 
Chris

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

Re: [PATCH 2/2] services: desktop: Use libmtp udev rules.

[Ludovic Courtès]

Chris Marusich <cmmarusich@gmail.com> skribis:

> * gnu/services/desktop.scm (%modified-base-services): New variable.
>   (%desktop-services): Use it.

I pushed a slightly more concise version of that in
3547a5effecfa19f73af29f0d503f5a231025672 (it also makes “mtp” show up in
‘guix system extension-graph’).

Thanks for the thorough investigation!

Ludo’.

Re: Let non-root users use MTP devices (Attempt #2)

[Ludovic Courtès]

Chris Marusich <cmmarusich@gmail.com> skribis:

> 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.

Cool!

> * gnu/packages/freedesktop.scm (elogind) [inputs]: Add acl.

Applied with a short comment.

Thank you!

Ludo’.

Re: Let non-root users use MTP devices (Attempt #2)

[Ludovic Courtès]

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’.

Re: [PATCH 2/2] services: desktop: Use libmtp udev rules.

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> * gnu/services/desktop.scm (%modified-base-services): New variable.
>>   (%desktop-services): Use it.
>
> I pushed a slightly more concise version of that in
> 3547a5effecfa19f73af29f0d503f5a231025672 (it also makes “mtp” show up in
> ‘guix system extension-graph’).
>
> Thanks for the thorough investigation!

Thank you!  I overlooked "simple-service".  Very handy!

-- 
Chris

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

Re: Let non-root users use MTP devices (Attempt #2)

[Chris Marusich]

[-- Attachment #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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]