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

[Chris Marusich]

Ricardo Wurmus <address@hidden> writes:

> Chris Marusich <address@hidden> 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

signature.asc
Description: PGP signature