© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
@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!