Specifying snap_daemon as user when running a snap application

snap
1

We have a snap (charmed-mysql) that is used in the mysql charm. We define a snap application for a mysql utility (mysqlsh) as outlined below:

layout:
    /var/log/mysqlsh:
        bind: $SNAP_COMMON/var/log/mysqlsh

apps:
    mysqlsh:
         command: run-mysqlsh.sh
         plugs:
             - network

The run-mysqlsh.sh script consists of the following:

#!/bin/bash

exec env MYSQLSH_USER_CONFIG_HOME=/tmp/mysqlsh $SNAP/usr/bin/mysqlsh --log-file /var/log/mysqlsh/mysqlsh.log "$@"

We would like to run this application (charmed-mysql.mysqlsh) with a specific user that has access to $SNAP_COMMON. However, we are unable to specify a specific user that we can run the snap application as.

We can use setpriv as follows:

#!/bin/bash
exec $SNAP/usr/bin/setpriv --clear-groups --reuid snap_daemon --regid snap_daemon -- env MYSQLSH_USER_CONFIG_HOME=/tmp/mysqlsh $SNAP/usr/bin/mysqlsh --log-file /var/log/mysqlsh/mysqlsh.log "$@"

However, doing so, we would need to run the snap application with sudo charmed-mysql.mysqlsh. We would like to avoid using sudo to run the snap application.

I would appreciate any direction or ideas to be able to specify snap_daemon to run charmed-mysql.mysqlsh or always run charmed-mysql.mysqlsh with snap_daemon

1 Like
2

We had discussions in the past about supporting user/group fields for services that would let specify system-usernames and have the service started under the given user/group.

We never discussed doing the same for apps that are not services, as snap-confine is setuid it would not be impossible. It’s a bit unclear that this would be a good idea in general security wise.

It’s a bit unclear to me if it’s a good idea to setup things such that any user can access this system-wide data? asking for sudo usage or for the user to add themselves to snap_daemon seems in line with unix practices but maybe I’m missing something.

Or is this about just the logs? Woulnd’t it make sense then for the logs to go to a per-user destination instead?