(hint from moderator: this is actually about providing per-snap shared data directories)
How does having $SNAP_COMMON and $SNAP_DATA root-only help with security?
Where can my app store a global config? Do my users need to run as root? Do I need to package an special sudo service to write global data?
This design doesn’t make sense to me - either as a feature or as security.
Within the context of the snap, SNAP_COMMON and SNAP_DATA being owned by root don’t help with security in practice per se, since a snap command can simply give data to a snap service to have the snap service put it in these directories. Within the context of the system, it does help with security since we don’t want snaps to default to world-writable directories where any user or non-snap process could modify the contents of those directories.
The way it is setup now mimics the behavior of a traditional Linux system where SNAP_COMMON and SNAP_DATA are for system-wide config and data and where SNAP_USER_COMMON and SNAP_USER_DATA are for user-specific config and data. This makes sense since, just like on a traditional Linux system, one user should not typically be able to modify the system-wide configuration of a snap for all users without needing sufficient privileges to do so. This is analogous to /etc vs ~/.config-- files in /etc are not writable by regular users and files in ~/.config don’t affect other users.
That said, snaps are free to manage config data in any manner they desire and they are free to create snap commands that talk to snap services over IPC so the service can write out files in the root-owned snap area. Snaps can also create temporary or world-writable directories in SNAP_DATA/SNAP_COMMON if they desire. However, I would strongly urge any snap developer to think very carefully about letting regular users modify snap-wide configuration without sudo/su since this is opening up the snap to abuse by ill-intentioned users and this behavior would almost always be considered a (security) bug in the snap.
@jdstrand thanks for the answer! Ok, that fits with my understanding of UNIX security.
Running my snap as a local user I can’t create files or directories in SNAP_COMMON or SNAP_DATA.
To do that, I’d have to run the service or snap as root which seems to me the opposite of a secure system. That’s pushing responsibility for security out of the design and onto the user. I get that the design is part of UNIX.
That’s ok for me, because I’m making the snap and anybody who wants to use it can sudo or write one themselves.
I think there’s a missing piece here which is place for private data to be shared among users of the snap. I hit this pretty early making snaps and others may too.
That’s a great suggestion, thank you! We may be able to do something very nice about it soon.
As an aside, that’s unrelated to security. The system is not more or less secure because of it (which is what @jdstrand covers with more details above). But it is indeed a nice (and probably unique in this context?) feature to offer software that is packaged as a snap.
That’s interesting. I’m not sure we actually want that, if I get what you mean. Let’s please have a call about this tomorrow to discuss in more detail (or when you have a slot of time).
To create a public area for users to share files with the snap, you or your snap can create a 1777 tmpdir-style directory in SNAP_DATA or SNAP_COMMON.
A “private area to be shared by users of the snap” is more difficult (since it implies that non-users of the snap should not be able to write to this area), but will be made possible when Multiple users and groups in snaps is implemented. You will be able to create a group for your snap and then add any users of your snap to that group, then create a dir with 0770, 1770 or 3770 permissions with root:yourgroup ownership (you can even do this now outside of the snap without official snapd support by creating the dir, creating a group, adding users to that group, setting the root:yourgroup ownership and setting the permissions on the dir).
Nice! Multiple users and groups in snaps
BTW, thanks guys, this is a huge problem and a huge service to the linux community 
