Services can only run as root

[Stuart Bishop]

PostgreSQL refuses to run as root and upstream very deliberately made it so this behaviour cannot be turned off. Even if I had a way of creating a user when the snap is installed, trying to drop privs with setuid/setgid fails.

My only current work around is to patch the source, removing the checks myself. Even if I could convince the extremely conservative upstream to rethink their choice and allow the checks to be disabled at configure or runtime it would not be available until the next major release.

I'd like for daemons to be able to drop their privileges. Lots of daemons try to drop privileges (usually to restricted accounts like nobody or daemon), so this should be possible without patching.

I'd like it possible to create users and groups as a snap preinstallation step. And I'd like to be able to declare these users and groups in snapcraft.yaml.

[Jamie Strandboge (jdstrand)]

I feel like there is already a bug on this but I can't seem to find it.

snap-confine now has the ability to filter arguments. This allows us to create policy for setuid, etc. Initially we will allow dropping to a non-root user that is already on the system (eg, 'daemon') which would fix this bug for you.

Eventually I think it would be nice to have snapcraft.yaml support for requesting a particular user. This needs to be designed, but I suspect allowing, opt-in, a user name that is the SNAP_NAME would be a stop along the path.

[Jamie Strandboge (jdstrand)]

I plan to implement the policy changes for using an already existing user in the coming weeks and that will appear as part of a future snapd release sometime after GA.

[Lars Tangvald (lars-tangvald)]

Just to note, this affects MySQL in the same way. The daemon will not run as root, so currently we can't store data in SNAP_DATA/SNAP_COMMON