Ricardo Wurmus writes: > Chris Marusich 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