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.