ACLs to devices need to be supported in core

[Alfonso Sanchez-Beato]

It should be possible to add a user to an ACL to be able to access some devices in the same way as on desktop. For instance, on desktop regular users are in an ACL that allows them to access /dev/snd/* so no root permissions are needed to play a song. But, on Ubuntu Core, we have to run commands like:

$ sudo alsa-utils.aplay /root/enter.wav

to play something (aplay is confined and connected to "alsa" and "home" interfaces). We cannot access /dev/snd and a file in $HOME at the same time, even while sudoing. ACLs can relieve these problems, but the core image currently does not support them.

[Oliver Grawert (ogra)]

we first need to seed the acl package in core ... given that systemd, uaccess scripts and logind are already present in core this might already be sufficient to have ACL based device access work.

[Jamie Strandboge (jdstrand)]

Per pitti:

09:14 < pitti> ogra_: right, /lib/udev/rules.d/70-uaccess.rules tags such devices as "uaccess" and 73-seat-late.rules calls the "uaccess" builtin

So, simply seeding acl will hopefully give us everything that 70-uaccess.rules and 73-seat-late.rules gives, which would be great for things like audio.

For things not covered by udev and systemd automatically, we could use setfacl to tag things via udev rules. Eg, serial devices are root:dialout 0660 and have no udev ACLs on them. Ubuntu Core systems can't update /etc/group because it is readonly and extrausers can't be used to add people to system groups. For a simple example, it would be possible to add a 'snap.dialout' group to extrausers and then add a udev rule to setfacl tty devices (or maybe use the uaccess mechanism) to 'snap.dialout' so that `sudo adduser --extrausers foo snap.dialout` would grant access to the tty devices. This could be done by a new ACL interface backend that deals with device access.

We could also integrate this directly into interfaces; this needs a bit of design but seems tractable. Eg:

 * serial-port interface adds snap.serial-port group to extrausers (if not present) and udev ACL for the serial port devices it handles
 * hidraw interface adds snap.hidraw group to extrausers (if not present) and udev ACL for the hidraw devices it handles
 * i2c ...
 * gpio ...
 * ...

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

@jdstrand why not directly add users to ACLs instead of using snap.* groups as proxies? Maybe a plug could specify the users that need access as arguments when performing the connection, like: I want root, <specialuser>, or <the user that installs the snap> to be added to the ACLs handled in the interface.

[Jamie Strandboge (jdstrand)]

@Alfonso, keep in mind, this is an idea, not a full-fledged spec proposal but to answer your questions:

"why not directly add users to ACLs instead of using snap.* groups as proxies?"

We could have documentation to use setfacl on a device so the user can simply add herself to the ACLs and have access. However, if the device is removable, the ACLs will be lost. Using a group with udev for the ACL means that things survive hotplug events. It would be possible to instead of use setfacl directly to have a snap command that uses setfacl-- this snap command would save the ACLs and apply them on boot or hotplug. This feels brittle. The same snap command could simply use extragroups and udev behind the scenes in the manner I described in comment #2 so the user doesn't have to know about all the groups.

"Maybe a plug could specify the users that need access as arguments when performing the connection, like: I want root, <specialuser>, or <the user that installs the snap> to be added to the ACLs handled in the interface"

I'm not sure exactly what the question is so I'll answer both of the interpretations I had. :)

If the snap.yaml specified the users in its plugs, that would be far too inflexible I think. Plug attributes are static in the snap. Consider a multi-user system where one user installs it but another uses it.

If you are talking about arguments for the plugs of the snap connect operation, tying the extragroups and udev logic described in comment #2 could be added behind the scenes-- it is an interface we are talking about and also for a particular slot so it makes a good bit of sense. On the other hand, if I want to give a user access to a slot, why should I have to use a snap connect command?

This needs design. I think handling users, groups and ACLs needs to be looked at holistically with bug #1606510 and the desire for opt-in per-snap users (eg, for privilege dropping in daemons). The discussions surrounding this bug sparked some ideas so I'll jot them down somewhere and share.

Thanks!

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

@Jamie, sure, I understand this is just an idea, I was mostly thinking loudly :). Good point about hotplug devices and ACLs. Re: plugs&users I actually thought about both posibilites on where to specify users (snap or in the connect command), but could not decide what was better, so great to see your thoughts on both.

Thanks for your detailed response!

[Oliver Grawert (ogra)]

i have seeded the acl package on all core snaps now, they should show up with tomorrows build, please check if this is sufficient already or if we need to take additional action.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

@ogra, I just tested edge and things work as expected (i.e. I can play music as a normal user by adding it to ACLs for files in /dev/snd/*).

[Jamie Strandboge (jdstrand)]

When looking at how to fix this, please consider https://bugs.launchpad.net/snappy/+bug/1606510/comments/14

[Jamie Strandboge (jdstrand)]

Discussion of snappy leveraging device ACLs has moved to the forum: https://forum.snapcraft.io/t/snappy-and-users-and-groups/331