Run MariaDB's Safe Helper Without Guessing Its User Boundary

You will verify the installed mariadbd-safe-helper, run a harmless child command through it, and send input to a named log file. The old mysqld_safe_helper name is a symlink to the MariaDB command on this machine. Allow about ten minutes. You need MariaDB Server installed, a shell, and a command that is safe to run as the selected account.

This is a small helper, not the MariaDB server and not the mariadbd-safe startup wrapper. Its installed manual page documents two forms only:

mariadbd-safe-helper <user> log  <filename>
mariadbd-safe-helper <user> exec <command> <args>

The first selects a log destination for standard input. The second runs a command with its arguments. The helper is normally an implementation detail of a safe server start-up path, so test it with a harmless command before putting it into a service configuration.

1. Check the installed version and both names

Start without elevated privileges. This only reads package metadata and follows the compatibility name:

$ mariadbd --version
mariadbd  Ver 10.11.14-MariaDB-0ubuntu0.24.04.1 for debian-linux-gnu on x86_64
$ command -v mariadbd-safe-helper
/usr/bin/mariadbd-safe-helper
$ ls -l /usr/bin/mysqld_safe_helper
... /usr/bin/mysqld_safe_helper -> mariadbd-safe-helper

Package revisions and paths vary. The checks above establish what is actually installed rather than assuming that a MySQL-era name identifies a MySQL binary. On this host the package is MariaDB Server 10.11.14.

2. Confirm that options are not a separate interface

The helper does not provide a normal --help or --version report. Missing arguments, and the option-looking arguments tested here, print the usage text and return status 1:

$ mariadbd-safe-helper --help
Usage:
  /usr/bin/mariadbd-safe-helper <user> log  <filename>
  /usr/bin/mariadbd-safe-helper <user> exec <command> <args>
$ printf 'status: %s\n' "$?"
status: 1

Do not copy options from mariadbd or mariadbd-safe and expect this helper to interpret them. Put the user first, choose exactly log or exec, and then supply the operands shown in the usage message.

3. Test command execution without changing a service

Use a command that reports its identity and exits. Keep the command and each argument as separate shell words:

$ mariadbd-safe-helper "$USER" exec /usr/bin/id -un
andy
$ printf 'status: %s\n' "$?"
status: 0

The word after exec is the executable. Everything after it is passed as an argument, so this is also a safe shape for a command with a value:

$ mariadbd-safe-helper "$USER" exec /usr/bin/printf '%s\n' helper-ok
helper-ok

Quote a user name, path or argument when it comes from a variable. Do not build one unquoted string containing a command line. That can change argument boundaries and can turn shell metacharacters into a command-injection problem when any part is externally controlled.

4. Check the user boundary before using another account

The first operand names the account that the helper is intended to use. Changing identity is a privileged operation. A non-root process cannot generally become another Unix user; on this host, running as the unprivileged account andy with nobody as the operand still produced andy from id -un.

$ mariadbd-safe-helper nobody exec /usr/bin/id -un
andy
$ printf 'status: %s\n' "$?"
status: 0

That status is not proof that the requested account was used. Check the identity inside the child, as above. If the helper is invoked by a root-owned service, the service definition and the target account's permissions become security boundaries. Review them before testing.

5. Send standard input to a log file

The log form takes the user followed by a filename. Use a new file in a scratch directory while learning the behaviour:

$ log_file="/tmp/mariadbd-safe-helper-check.log"
$ printf 'helper test line 1\nhelper test line 2\n' |
>   mariadbd-safe-helper "$USER" log "$log_file"
$ printf 'status: %s\n' "$?"
status: 0
$ sed -n '1,5p' "$log_file"
helper test line 1
helper test line 2

On the installed binary, the log form completed successfully and the file contained the two lines supplied on standard input. The helper did not print a normal success message, so check the exit status and inspect the destination. Do not put secrets, database passwords or untrusted multi-user data into a log merely because the filename is writable.

File permissions matter. If a privileged service creates the log, decide who should read it before starting the service. If it must be replaced, stop the owning service first and preserve a copy according to your retention policy. Do not truncate a live MariaDB log blindly: it can remove evidence needed to diagnose a failed start.

6. Diagnose the common mistakes

A usage message with status 1 usually means the operands are missing or in the wrong order. Compare the command with these exact shapes:

$ mariadbd-safe-helper "$USER" log  /tmp/helper.log
$ mariadbd-safe-helper "$USER" exec /usr/bin/id -un

If execution fails, first check the executable without changing anything:

$ command -v /usr/bin/id
/usr/bin/id
$ test -x /usr/bin/id && echo executable
executable

If logging fails, check the parent directory and whether the destination is writable. A filename is not a directory, and a path that the invoking shell can write may not be writable after a privileged helper changes identity. Keep the input on standard input rather than adding it as an extra argument to the log form.

For a failed scratch test, the recovery is simple: leave the original input untouched, choose a different temporary destination, and rerun the read-only identity check. If you changed a service unit or wrapper while integrating the helper, restore the previous file from your configuration backup and restart the service only during an approved maintenance window.