I have written a program grpusr and published it as a snap which requires read-only access to two system files, both of which are publicly readable:
/etc/group
/etc/passwd
Pursuant to the review (thankyou Alex) I submit this request for access to system-files interface and auto-connection.
system-files appears to be the most appropriate interface in order to access the two files however if a more suitable alternative exists I would love to learn what it is and explore that.
A primer on the program
grpusr is a simple utility which queries /etc/group and /etc/passwd (or two similarly formatted alternatives) for group membership information. Whilst it can do single user-group membership checks, it becomes much more useful when checking a list of users belong to one or more groups. The program doesn’t write any data and it doesn’t connect to a network.
Examples:
Example 1
Check whether a single user exists in a single group
Usage:
$ snap run grpusr lxd:daniel
Output:
Group 'lxd' contains user 'daniel'
return code: 0
Example 2
Check whether a multiple users exist in a single group
Usage:
$ snap run grpusr lxd:daniel,postgres
Output:
Group 'lxd' contains user 'daniel'
Group 'lxd' does not contain user 'postgres'
return code: 1
Example 3
Check whether a multiple exist users in multiple groups
Usage:
$ snap run grpusr \
lxd:daniel,root \
adm:daniel,root,postgres
Output:
Group 'adm' contains user 'daniel'
Group 'adm' does not contain user 'postgres'
Group 'adm' does not contain user 'root'
Group 'lxd' contains user 'daniel'
Group 'lxd' does not contain user 'root'
+1 from me for granting grpusr snap read access to /etc/group and /etc/passwd via system-files interface auto-connection, considering that this information is not shared over the network.
As a more general though when private information is involved, one thing that weights the decision to grant access to that information or not, is what the information is going to be used for (specially relevant whether the information needs to leave the user’s computer or not). Sometimes it will be acceptable to grant auto-connection if the information is not going to be shared in anyway, but we may prefer to let the user decide (with manual connection) is the information may be sent over the network.
In that sense, I wonder if it will be a good practice in those cases to add explicit deny conditions to the snap declaration for network related interfaces when its use (or not use) may weight the decision to grant access to some private information. Thus, future changes do not go unnoticed. @alexmurray thoughts?
Thank you for your positive feedback and support @jslarraz.
Explicit deny-network policy
I think the ability to explicitly agree that network access is not required would be a good move in general for snap package security and visibility. Many applications may never need to access the network and it would be beneficial to declare that.
If necessary, a subsequent request to review/ alter that agreement could be made with appropriate justification.
Appetite for a less privileged system-files interface
Is there an appetite for the creation of a less sensitive/ privileged interface than system-files, with read-only capability for already globally readable files.
The proposition:
Everyone can already read the file by design
The file is deemed to have low-sensitivity by the system
There is no opportunity for network egress
There are no filesystem changes
is far less threatening than:
Requires access to the information in the super sensitive /etc/ hierarchy
A note for future Daniel and reviews: I have subsequently learnt of /etc/subuid and /etc/subgid which I will likely integrate into grpusr at a later date.
hey @DWD
After understanding the requirements for this snap, +1 from me as well for granting an auto-connect request to grpusr snap read access to /etc/group and /etc/passwd via system-files interface
hi @DWD, sorry for the delay in getting this one processed!
+2 votes for, 0 votes against, granting auto-connect of interface system-files to snap grpusr. Before making this snap live, would it be possible to adjust the interface formatting to match the example seen in https://snapcraft.io/docs/system-files-interface.
That being separating the two files into their own system-files plug?
Thanks @cav . The project source is not published, it remains private for now. That might change in the future.
I have a (purposely) sparse GitHub profile where you should see two PRs into Snapcraft itself, merged by @mr_cal . I might be able to find a few people to give character references if necessary?
Please let me know what I can do to facilitate the vetting process
Hey @cav ,having removed those plugs, the snap does still work on my laptop with --dangerous enabled.
I can’t upload it because of this:
Waiting for previous upload(s) to complete their review process. If you want to prioritize this last one, go to the other upload(s) page in https://dashboard.snapcraft.io/ and click on the ‘Reject and remove from review queue’ button.