SNAP_COMMON writable by default?

I have a snap running in devmode, and I am trying to persist some state information to be used between versions in the folder: \var\snap<name>\common\ aka $(SNAP_COMMON)

Is this writable by default? Or do I need to do anything to enable write permission? (ie create a plug/content interface in the snapcraft.yaml)

When my snap attempts to create a file the common folder i get an error: “access to path is denied”

SNAP_COMMON is writable by your snap, but may not be writable by the user invoking your snap. Put another way, SNAP_COMMON is owned by ‘root:root’ with ‘0755’ permissions, so daemons of your snap can write to it. If your snap command is meant to be called by non-root, you might be interested in the SNAP_USER_COMMON directory that is in the invoking user’s home directory. Alternatively, your snap could create a subdirectory in SNAP_COMMON and then chmod it to something (eg, 1777).

ok that makes sense! I guess to fully “simulate/test” the snap, i should really run “sudo snap run --shell < snap >” (then it works!)

if you expect that users will use your snap on normal systems then you should “simulate/test” your snap using the methods that they’re likely to use. Running as root, even for snapped apps, is a bad idea for normal users of a system. Encouraging sudo before any command is bad practice. Your snap should be capable of running under an unprivileged account unless it only runs as a daemon via systemd (or is otherwise a privileged app which must run as root even when not in a snap package), in which case it will be running as root by default as is standard practice for daemons who might then drop privileges once started.

the snap will only be a daemon… regarding privileges, do snap daemons have to follow the plug semantics? I was working on trying out the interfaces plug/snaps for network access… but it seems that the daemon already has network access… which would make sense if it is running as root.

It does not matter if your snap is using the root user or not, the interface implementation is the same in all cases, all plug/slot semantics apply regardless if it is a user started app or a daemon …

Even for classic confinement?

The daemon I am writing is not something that would ever be run on a user system… its more hardware related. I am curious if classic confinement is the way to go, but the term sounds like something that might be deprecated?

Sorry if these are rudimentary issues… I am quite new to snap, but in the limited time i have used it, I am quite impressed!

No, indeed … classic confinement means confinement is non-existent … which is the reason you cant just upload classic snaps to the store without a detailed manual review of the snap by some humans … (while strict and devmode confined snaps simply go in after an automated check)

Classic snaps are like the typical self contained tarball that installs an application and all its libs to /opt, just with a update/rollback feature, but beyond this they do not benefit from any snap features …

Update and Rollback are wonderful snap features! :slight_smile:

I am trying to avoid classic mode, but something tells me I might eventually need to go that road.

Depending on one’s needs, using sticky and sgid on the root:root owned dir could be useful. Eg: test -d $SNAP_COMMON/dir || mkdir -m 3777 $SNAP_COMMON/dir. With an appropriate umask (eg, 027 or 007), then users would be able to create files in this directory that a snap service (that runs as root) could access.