OS: Debian GNU/Linux (unstable)
Package: mariadb-server-10.6 (version 1:10.6.10-1)

Because mysql_install_db passes --user mysql to the mariadbd server process, and the server process does setuid to the mysql user, the $TMPDIR isn't changed from the root user.

Running su -l mysql mysql_install_db ...

Might trigger the pam bits to set $TMPDIR to the path for the mysql user. If you could test that it would be appreciated.

I believe

su -l mysql ...

is not working (perhaps because mysql user is not allowed to have a shell). My test:

root@testing:~# su -l mysql -c 'echo test'

root@testing:~# echo $?

1

root@testing:~# su -l root -c 'echo test'

test

root@testing:~# getent passwd mysql

mysql:x:116:120:MySQL Server,,,:/nonexistent:/bin/false

root@testing:~# rm -rf /var/lib/mysql ; su -l mysql -c 'mysql_install_db --rpm --cross-bootstrap --user=mysql --disable-log-bin --skip-test-db'

root@testing:~# echo $?

However, bypassing the disabled shell for mysql user using sudo works as I tried in one of the workarounds:

root@testing:~# rm -rf /var/lib/mysql ; mkdir /var/lib/mysql; chown mysql:mysql /var/lib/mysql/ ; sudo -u mysql mysql_install_db --rpm --cross-bootstrap --user=mysql --disable-log-bin --skip-test-db

2022-10-28 22:43:44 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.

A MR to fix this in Debian directly was submitted at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/23 the the same author. Thanks Sunil!

Thanks for testing. I was wondering about locked accounts. sudo probably isn't always available.

Setting TMPDIR to empty is a nice, probably portable fix for pushing into mysql_install_db.

Thank you for good bug report sunil.

After little bit digging this I like to ask some questions if I understood correctly. does I understand correctly that pam-tmpdir does this:

1. Create dir

   /tmp/users

   with chmod 0711 (rwx-x-x) which is little problematic but if it's always run by root when creating new tmp-dir then it works

2. After that it create

   /tmp/users/uid

   in this case as we use root it's

   /tmp/users/0

   with chmod 0700 (rwx------)

3. Then try to write to

   /tmp/users/0

   with user mysql

4. Fail with error message

I would see that TMPDIR should be filled with

mkstemp

neither than just unset it.

1. Create dir

/tmp/users

with chmod 0711 (rwx-x-x) which is little problematic but if it's always run by root when creating new tmp-dir then it works

It looks like /tmp/users is created by the PAM module with superuser privileges. I did the following to confirm:

root@freedombox:~# rm -rf /tmp/user
root@freedombox:~# exit

(SSH into machine as user fbx)
fbx@freedombox:~$ ls -lad /tmp/user/
drwx-x-x 3 root root 60 Nov 7 10:22 /tmp/user/
fbx@freedombox:~$ ls -lad /tmp/user/$UID
drwx------ 2 fbx root 40 Nov 7 10:22 /tmp/user/10000

Thank you for fast reply. Need little bit digging and testing on my side to get this straight. danblack do you have opinion on this?

Opinion on "I would see that TMPDIR should be filled with mkstemp neither than just unset it.":

• If you're thinking of something like TMPDIR=$(mktemp -d) in the mysql_install_db then that would create a root:root 700 permission directory that --user=mysql wouldn't be able to write to. chown to user, problematic, path might be not +x, and selinux/apparmor restrictions could apply.
• Or are you thinking of EPERM errors in the server code to call mkstemp and changing the env TMPDIR (or DEFAULT_TMPDIR) there to the created directory? Messy, but plausible.

I don't know the exact code we are talking about here but in order for 'mysql' user to get a proper value for TMPDIR, one could start a proper PAM session. So, instead of doing sometime like 'setuid ; do task' one could do 'su -c task'.