[Maria-discuss] demo: running MariaDB with rootless Podman and socket activation
Hi, Support for socket activation was added to MariaDB in release 10.6 (released April 2021). Podman also supports socket activation so I thought it would be interesting to combine both of them into a systemd user service. I wrote a small demo: https://github.com/eriksjolund/mariadb-podman-socket-activation (tweet: https://twitter.com/eriksjolundcomp/status/1491162016429768704) and got it to work. Do you have any suggestions on how to improve this? Thanks, Erik Sjölund
Erik, Thanks for the email and repository. On Wed, Feb 9, 2022 at 9:18 AM Erik Sjölund <erik.sjolund@gmail.com> wrote:
Hi, Support for socket activation was added to MariaDB in release 10.6 (released April 2021). Podman also supports socket activation
Nice. I saw some bits around sdnotify but didn't realize full socket activation was there.
so I thought it would be interesting to combine both of them into a systemd user service.
I wrote a small demo: https://github.com/eriksjolund/mariadb-podman-socket-activation (tweet: https://twitter.com/eriksjolundcomp/status/1491162016429768704)
and got it to work.
Do you have any suggestions on how to improve this?
I did a few suggestions in https://github.com/eriksjolund/mariadb-podman-socket-activation/pull/1 (tcp changes probably mirror these). In general from what I've learnt with podman and systemd, the more you can keep to the defaults the better. There's some really powerful concepts with unix_socket auth across into the container if you get the uid mapping, try to map the local %u (uid - %U) to the mysql(999) user (or another user and start the container with --user). You'll probably need to add a user to the container. With that you'll have a unix socket auth based mechanism in the container directly. Also the current container entrypoint avoids creating unix socket auth users (until very recently in a limited way https://github.com/MariaDB/mariadb-docker/pull/409). Maybe its too fiddly however to get right. The mariadb has the service Restart as: # Restart crashed server only, on-failure would also restart, for example, when # my.cnf contains unknown option Restart=on-abort If conmon acts a true passthough maybe the same option is needed. I guess try with some invalid configuration. In my talk https://lca2022.linux.org.au/schedule/presentation/18/ I did get asked about systemd --user implemented and new it wasn't too hard. Thanks for going a step further and integrating with podman. Thanks for sharing.
Thanks, Erik Sjölund
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Hi Daniel, Thanks for the feedback. On Thu, Feb 10, 2022 at 4:40 AM Daniel Black <daniel@mariadb.org> wrote:
Erik,
Thanks for the email and repository.
On Wed, Feb 9, 2022 at 9:18 AM Erik Sjölund <erik.sjolund@gmail.com> wrote:
Hi, Support for socket activation was added to MariaDB in release 10.6 (released April 2021). Podman also supports socket activation
Nice. I saw some bits around sdnotify but didn't realize full socket activation was there.
so I thought it would be interesting to combine both of them into a systemd user service.
I wrote a small demo: https://github.com/eriksjolund/mariadb-podman-socket-activation (tweet: https://twitter.com/eriksjolundcomp/status/1491162016429768704)
and got it to work.
Do you have any suggestions on how to improve this?
I did a few suggestions in https://github.com/eriksjolund/mariadb-podman-socket-activation/pull/1 (tcp changes probably mirror these).
Thanks, I'll take a look.
In general from what I've learnt with podman and systemd, the more you can keep to the defaults the better.
I agree.
There's some really powerful concepts with unix_socket auth across into the container if you get the uid mapping, try to map the local %u (uid - %U) to the mysql(999) user (or another user and start the container with --user). You'll probably need to add a user to the container. With that you'll have a unix socket auth based mechanism in the container directly. Also the current container entrypoint avoids creating unix socket auth users (until very recently in a limited way https://github.com/MariaDB/mariadb-docker/pull/409). Maybe its too fiddly however to get right.
I've recently submitted a PR https://github.com/containers/podman/pull/13084/files to the Podman project that adds two troubleshooting tips regarding UID/GID mapping. They describe how to run the container with a non-root user inside the container but mapped to the regular UID/GID on the host. As the PR has not yet been approved, the easiest way to read it, is directly in my branch https://github.com/eriksjolund/podman/blob/troubleshooting_userns_keep_id_ui... Using the same method for MariaDB, it could look like this [test@laptop ~]$ cat script.sh #!/bin/bash uid=999 gid=999 subuidSize=$(( $(podman info --format "{{ range .Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 )) subgidSize=$(( $(podman info --format "{{ range .Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 )) podman run --rm \ -v ./data:/var/lib/mysql:Z \ --env MARIADB_USER=example-user \ --env MARIADB_PASSWORD=my \ --env MARIADB_ROOT_PASSWORD=my_root \ --detach \ --name test1 \ --user $uid:$gid \ --uidmap $uid:0:1 \ --uidmap 0:1:$uid \ --uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) \ --gidmap $gid:0:1 \ --gidmap 0:1:$gid \ --gidmap $(($gid+1)):$(($gid+1)):$(($subgidSize-$gid)) \ docker.io/library/mariadb:latest [test@laptop ~]$ bash script.sh 774a4943aca385d0f96a2ed5d00e319ad88165f140203ae537612f36291d49ad [test@laptop ~]$ podman exec -ti test1 ps -u mysql PID TTY TIME CMD 1 ? 00:00:00 mariadbd 140 pts/0 00:00:00 ps [test@laptop ~]$ mariadb is running as the user mysql inside the container. I guess this method would work with $MARIADB_MYSQL_LOCALHOST_GRANTS I had an idea regarding "unix_socket authentication": Permissions could be granted to specific Unix sockets by using FileDescriptorName [test@laptop ~]$ man systemd.socket | grep -A2 FileDescriptorName= FileDescriptorName= Assigns a name to all file descriptors this socket unit encapsulates. This is useful to help activated services identify specific file descriptors, if multiple fds are passed. Services may use the sd_listen_fds_with_names(3) call to acquire the names configured for the received file descriptors. Names may contain any ASCII character, but must exclude control characters and ":", and must be at most 255 characters in [test@laptop ~]$ If the permissions are given to a specific Unix socket, a sysadmin could create multiple Unix sockets with different levels of permissions. There would be no need to rely on "calling the getsockopt system call with the SO_PEERCRED socket option, which allows it to retrieve the uid of the process that is connected to the socket." quote from https://mariadb.com/kb/en/authentication-plugin-unix-socket/#is-it-secure A sysadmin could instead protect the Unix socket from unauthorized access by using normal file and directory permissions.
The mariadb has the service Restart as: # Restart crashed server only, on-failure would also restart, for example, when # my.cnf contains unknown option Restart=on-abort
If conmon acts a true passthough maybe the same option is needed. I guess try with some invalid configuration.
Thanks for the tip.
In my talk https://lca2022.linux.org.au/schedule/presentation/18/ I did get asked about systemd --user implemented and new it wasn't too hard.
I see there is a link with "Attendee notes:". Interesting.
On Mon, Feb 14, 2022 at 6:37 PM Erik Sjölund <erik.sjolund@gmail.com> wrote:
Hi Daniel, Thanks for the feedback.
On Thu, Feb 10, 2022 at 4:40 AM Daniel Black <daniel@mariadb.org> wrote:
There's some really powerful concepts with unix_socket auth across into the container if you get the uid mapping, try to map the local %u (uid - %U) to the mysql(999) user (or another user and start the container with --user). You'll probably need to add a user to the container. With that you'll have a unix socket auth based mechanism in the container directly. Also the current container entrypoint avoids creating unix socket auth users (until very recently in a limited way https://github.com/MariaDB/mariadb-docker/pull/409). Maybe its too fiddly however to get right.
Nice!
I've recently submitted a PR https://github.com/containers/podman/pull/13084/files to the Podman project that adds two troubleshooting tips regarding UID/GID mapping. They describe how to run the container with a non-root user inside the container but mapped to the regular UID/GID on the host.
Nice read. Thanks. The implied user but defaulting to root nature of the mariadb container with gosu took a bit to get used to. Some sane mapping rules help thanks.
As the PR has not yet been approved,
now approved I see.
I had an idea regarding "unix_socket authentication": Permissions could be granted to specific Unix sockets by using FileDescriptorName
interesting. The "extra" is used as a FDName for extra sockets but its a generally unexplored space.
If the permissions are given to a specific Unix socket, a sysadmin could create multiple Unix sockets with different levels of permissions. There would be no need to rely on
"calling the getsockopt system call with the SO_PEERCRED socket option, which allows it to retrieve the uid of the process that is connected to the socket." quote from https://mariadb.com/kb/en/authentication-plugin-unix-socket/#is-it-secure
If you've got a good general use case, write a https://jira.mariadb.org task.
A sysadmin could instead protect the Unix socket from unauthorized access by using normal file and directory permissions.
MySQL's implementation also extends by using the "AS ..." syntax to extend coverage to one other user. https://dev.mysql.com/doc/refman/8.0/en/socket-pluggable-authentication.html...
If conmon acts a true passthough maybe the same option is needed. I guess try with some invalid configuration.
seems there are some conman aspects I need to understand more.
participants (2)
-
Daniel Black
-
Erik Sjölund