Am I correct in thinking the user-facing keys are created whenever the configure hook calls snapctl get? I’ve seen snaps (such as nextcloud) which list the available keys whenever the user calls sudo snap get snapname, even if those keys/values are still unset. My snap doesn’t do that. What am I missing?
The documentation says the configure hook should iterate over all the keys with snapctl get and write them to a file. Is there a reason for this as the key/values will be duplicated between the file and the internal snapctl database? Can I skip this step and just get my app to call snapctl get directly to get the config values as needed?
I’ve created a bare config file which gets written to $SNAP_DATA by the install hook. As the config file will contain plaintext passwords, I planned to chmod 600 to prevent casual observation. However, my app cannot read that file unless it is set to +r for all. Should this file be chown'ed to a special user to permit the app to read without exposing the contents to the world? Am I missing something daft?
I’ve noticed snapctl will reject certain keys (such as key which contain underscores). Is there a sensible reason for this? Is the acceptable key format documented anywhere?
Thanks for taking the time to read, and very special thanks if you take the time to reply!
No, snapctl doesn’t work this way. You cannot call sudo snap get snapname foo without having something set foo for the snap, first. However, in the case of the Nextcloud snap, snap configuration is abstracted away from the rest of the snap by shell functions. For example, this one. When it’s called, it uses snapctl get <whatever>, but if that doesn’t return anything, it then sets its default values. As a result, the first time the snap fires up, it runs snapctl set for all configurable things and sets them to their default values.
The Nextcloud snap existed long before hooks, so some of this is historical. Today you can use e.g. the install or post-refresh hooks to set initial values, etc.
I’m not sure about the documentation to which you refer here, but you’re right: there’s no need to duplicate the config unless what you’re snapping can only operate on, say, a text file. It’s fine to rely on snapd to store your config.
This is just good old permissions. If your app is a service, it’s running as root, in which case you can simply ensure the config file is owned by root, chmod 600, and you’re good to go. Unfortunately, if it’s not a service, then you have no idea who will be running the app, and you can no longer use 600-- you’re essentially requiring that the world must be able to read this file, which may not be the best idea.
I don’t believe this is well-documented, but it’s validated here, so essentially lowercase alpha-numerics and hyphens.
