Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-35569

MariaDB docker failed to start with --skip-grant-tables in cmd arguments or skip_grant_tables=ON in the configuration file

Details

    Description

      Description

      When we start the mariadb docker with `--skip-grant-tables` option, the docker exited 1 and failed due to the following error

      --------------
      DROP USER IF EXISTS root@'127.0.0.1', root@'::1'
      --------------

      ERROR 1290 (HY000) at line 7: The MariaDB server is running with the --skip-grant-tables option so it cannot execute this statement

      This issue can also be reproduced with skip_grant_tables=ON in the mariadb configuration file.

      This issue is caused by the conflict between the DROP USER IF EXISTS root@'127.0.0.1', root@'::1' from the MariaDB's docker entrypoint script at [here](https://github.com/MariaDB/mariadb-docker/blob/master/11.7/docker-entrypoint.sh#L489) and the `--skip-grant-tables` option.

      How to repeat

      Pull the latest docker image of mariadb:

      docker pull mariadb:latest

      Start MariaDB Docker with `--skip-grant-tables` option:

      docker run --name mariadbtest -e MYSQL_ROOT_PASSWORD=mypass -d mariadb:latest --skip_grant_tables

      Check the status of mariadb docker and see the status of it to be `Exited (1)`:

      docker ps -a

      Check the logs of mariadb docker instance:

      docker logs mariadbtest

      which outputs the following log:

      --------------
      DROP USER IF EXISTS root@'127.0.0.1', root@'::1'
      --------------

      ERROR 1290 (HY000) at line 7: The MariaDB server is running with the --skip-grant-tables option so it cannot execute this statement

      The root cause is that during the initialization of the MariaDB Docker container, the `docker-entrypoint.sh` script runs the query `DROP USER IF EXISTS root@'127.0.0.1', root@'::1'`. However, this query fails to execute when `--skip-grant-tables` is enabled. As a result, the entrypoint script of MariaDB container exits with error 1 and the MariaDB container crashes.

      Suggested fix

      The fix of this issue is to find an alternative way to run the [DROP command](https://github.com/MariaDB/mariadb-docker/blob/master/11.7/docker-entrypoint.sh#L489) when `--skip-grant-tables` option is used.

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-27435 Support extra initialization file for mysql_install_db

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-35668 --bootstrap user don't have proxy privs so cannot grant it

          • Major - Major loss of function.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            danblack Daniel Black added a comment -

            Why is it important to run in --skip-grant-tables?

            Even resolving the DROP USER command would still fail on creating the new user.

            danblack Daniel Black added a comment - Why is it important to run in --skip-grant-tables ? Even resolving the DROP USER command would still fail on creating the new user.
            kubernetes.operator.study KOS added a comment - - edited

            To be able to drop and create users while running with the --skip-grant-tables, we can first run the `FLUSH PRIVILEGES;` command before any user creation/drop operations. Since the `FLUSH PRIVILEGES;` command is not reversible, the system needs to be restarted with the
            --skip-grant-tables so that the system runs with the correct configuration at the end.

            Such procedure already exists in the entrypoint script in the mariadb_upgrade logic where the temp servers are started using the --skip-grant-tables option: https://github.com/MariaDB/mariadb-docker/blob/master/11.7/docker-entrypoint.sh#L606C1-L630C4

            kubernetes.operator.study KOS added a comment - - edited To be able to drop and create users while running with the --skip-grant-tables , we can first run the `FLUSH PRIVILEGES;` command before any user creation/drop operations. Since the `FLUSH PRIVILEGES;` command is not reversible, the system needs to be restarted with the --skip-grant-tables so that the system runs with the correct configuration at the end. Such procedure already exists in the entrypoint script in the mariadb_upgrade logic where the temp servers are started using the --skip-grant-tables option : https://github.com/MariaDB/mariadb-docker/blob/master/11.7/docker-entrypoint.sh#L606C1-L630C4
            danblack Daniel Black added a comment - - edited

            So what I was achieving with the current implementation was that the server didn't restart between the system initialization and the /docker-entrypoint-initdb.d.

            The assumption was a MARIADB_ROOT_PASSWORD was available to service needs like yours where there was more CREATE/DROP alter users. So I'm assuming you are using MARIADB_ROOT_PASSWORD_HASH as this might be one of the few/only case where are MARIADB_ROOT_PASSWORD isn't there.

            One option is for the root@localhost to be able to retain its unix_socket authentication on the basis that anything execing in a container as root as all access to the data anyway so its not exposing anything (removing --auth-root-authentication-method=normal).

            Since 10.10, skip_grant_tables is a system variable so I could avoid (or delay) the DROP USER based on this setting. Should I just error if user creation environment options and --skip-grant-tables are presented? For 10.5/10.6 an implementation is still possible, but it would involve a temporary stored procedure with error handing.

            danblack Daniel Black added a comment - - edited So what I was achieving with the current implementation was that the server didn't restart between the system initialization and the /docker-entrypoint-initdb.d. The assumption was a MARIADB_ROOT_PASSWORD was available to service needs like yours where there was more CREATE/DROP alter users. So I'm assuming you are using MARIADB_ROOT_PASSWORD_HASH as this might be one of the few/only case where are MARIADB_ROOT_PASSWORD isn't there. One option is for the root@localhost to be able to retain its unix_socket authentication on the basis that anything execing in a container as root as all access to the data anyway so its not exposing anything (removing --auth-root-authentication-method=normal ). Since 10.10, skip_grant_tables is a system variable so I could avoid (or delay) the DROP USER based on this setting. Should I just error if user creation environment options and --skip-grant-tables are presented? For 10.5/10.6 an implementation is still possible, but it would involve a temporary stored procedure with error handing.
            kubernetes.operator.study KOS added a comment -

            Since 10.10, skip_grant_tables is a system variable so I could avoid (or delay) the DROP USER based on this setting.

            This sounds a sensible approach and would resolve our issue.

            Should I just error if user creation environment options and --skip-grant-tables are presented?

            Explicitly erroring out in this case sounds good as it makes the behavior more explicit and prevent potential confusion.

            Thank you for the detailed comments and the help!

            kubernetes.operator.study KOS added a comment - Since 10.10, skip_grant_tables is a system variable so I could avoid (or delay) the DROP USER based on this setting. This sounds a sensible approach and would resolve our issue. Should I just error if user creation environment options and --skip-grant-tables are presented? Explicitly erroring out in this case sounds good as it makes the behavior more explicit and prevent potential confusion. Thank you for the detailed comments and the help!
            danblack Daniel Black added a comment -

            it occurs to me MDEV-27435 (10.11+) add --extra-file to the mariadb-install-db command for the early initialization.

            danblack Daniel Black added a comment - it occurs to me MDEV-27435 (10.11+) add --extra-file to the mariadb-install-db command for the early initialization.
            danblack Daniel Black added a comment -

            Made an attempt and its really ugly

            https://github.com/grooverdan/mariadb-docker/commit/ab8cecfb4297d6ba2cc7e596344df6beca935af3

            danblack Daniel Black added a comment - Made an attempt and its really ugly https://github.com/grooverdan/mariadb-docker/commit/ab8cecfb4297d6ba2cc7e596344df6beca935af3

            People

              danblack Daniel Black
              kubernetes.operator.study KOS
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.