From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: [PATCH 1/2] gnu: libmtp: Grant "audio" group access to device files. Date: Wed, 28 Dec 2016 03:18:03 -0800 Message-ID: <87mvfggv4k.fsf@gmail.com> References: <20161226005905.1796-1-cmmarusich@gmail.com> <20161226005905.1796-2-cmmarusich@gmail.com> <871swvkkde.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMCFJ-0007AH-0o for guix-devel@gnu.org; Wed, 28 Dec 2016 06:18:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMCFH-0000c5-Ef for guix-devel@gnu.org; Wed, 28 Dec 2016 06:18:13 -0500 Received: from mail-pg0-x244.google.com ([2607:f8b0:400e:c05::244]:35744) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cMCFH-0000bQ-5r for guix-devel@gnu.org; Wed, 28 Dec 2016 06:18:11 -0500 Received: by mail-pg0-x244.google.com with SMTP id i5so15482480pgh.2 for ; Wed, 28 Dec 2016 03:18:09 -0800 (PST) In-Reply-To: <871swvkkde.fsf@elephly.net> (Ricardo Wurmus's message of "Mon, 26 Dec 2016 14:58:34 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ricardo Wurmus writes: > Chris Marusich writes: > >> * gnu/packages/libusb.scm (libmtp): Set udev group to "audio". >> --- > > I just checked how it=E2=80=99s 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=E2=80=99t mean that we should not do this, but it=E2=80=99s su= spicious. > Maybe there=E2=80=99s something else we=E2=80=99re 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 =E2=80=9Caudio=E2=80=9D group would be wrong.= This is for > MTP devices, so maybe it would be better to add an =E2=80=9Cmtp=E2=80=9D = 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. [=E2=80=A6] On Linux, in general No, as libmtp should have set you= r 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=E2=80=99s= 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!! :-) =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlhjn2wACgkQ3UCaFdgi Rp3KPxAAjeXHmnSy6kpft5XFylyttESEGQjO2f8MmKTWR9koNLSU9NMjM9wBSaZt jcOJ/83cMIhGnFAXUjGwza06ByHfiH9iPROR5K3UQmkobz4PVACxf0u41WZPdnbg o7lb8IzFZWM7fJDtz8hXetTfLqMbwHPcQznjL1zxwCxBbu9b+n0fUfUvEp/N9w9O SMVj0kYQSAViep9EVETJe+DOk88ZGRs1/fcSCPawFOVEXFbuf+G3QWpKXWSzmObK 1HFK1KR7V951bJjC1+B1+md27WwzP0bZsMzzFT8doY6EIfs5aN5ZqNQpVJ+5eSlf z+JKNzmxzgDuwbqYcEHNpcetA4P1N4bnKCRNnEF0FUodaAi9ZLFewsc1p0PbKxoP q0IrPAl1axEE+mzsTwFyXZeiWAsIfs9wYKwiKVqtzeDbSbq2mfGG3V0EDoevnxum DSLgbIVmnHD/JUFsHEswcLVH5EHpuMykWx9duLenknNc9PoYv+2heckWlNktJ/S/ 1zdTaq9qqyt4uGbZ/32RQ11mpuUza9FzfCQ9bmZa8He07oGDOmnaW6LzD2prQI8v V/sHghDXJEwTdO3ij8HWuhZrfSxhnoltsYLC8R2bYnVFxzGCgcmm4a+98kCvwB4d ISXWchelDKKwlwz8Sv+chNEfNhPaSpcZyDnLSVl9pp7s63fQuA0= =8Rif -----END PGP SIGNATURE----- --=-=-=--