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

DROP USER should leave no active session for that user

Details

    • Q2/2025 Development

    Description

      DROP USER deletes specified user, while there is connected session of user deleted. After deletion user is still able to select or modify data in that session. Is that a bug or designed behavior? How can I prevent deleted user from further actions in that session?

      Version:11.4.2-MariaDB

      Voting initiated on the page https://mariadb.org/tell-us-how-to-drop-user/ gives the result shown in the attachments section.
      In according with voting results, the most popular choice on possible behavior of the statement "DROP USER" seems to be "Terminate all existing connections of the user". But note that the set of choices was not mutually exclusive. There were only three mutually exclusive choices "Keep the old behaviour", "DROP USER should terminate all existing connections", "DROP USER should wait". And the third option "should wait" got the most votes. Also, most of people who thought that DROP USER should wait, also thought there should be a FORCE option.

      Summing up the survey, server should do the following steps on executing the DROP USER statement:

      • Server stops accepting any connections on behalf the user being dropped
      • In case the option `FORCE` is NOT specified for DROP USER statement, MariaDB server is waiting until all connections established on behalf the user specified by DROP USER statement be disconnected
      • The specified user is dropped
      • In case the option FORCE is specified for DROP USER statement, all active connections be forcibly terminated

      Attachments

        Issue Links

          blocks

          Bug - A problem which impairs or prevents the functions of the product. MDEV-36429 Counters of used resources are not reset when account is recreated

          • Major - Major loss of function.
          • Open
          is blocked by

          Task - A task that needs to be done. MDBF-996 Blog about the idea of disconnecting users after DROP USER

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed
          links to

          Web Link Tell us how to DROP USER!

          Activity

            Ascending order - Click to sort in descending order
            serg Sergei Golubchik added a comment -

            This is intended behavior. At least it was intended when this code was implemented, more than 20 years ago.

            I agree it might not be desirable anymore, so while this behavior is certainly not a bug, changing it is a feature request that we should consider. Thanks!

            serg Sergei Golubchik added a comment - This is intended behavior. At least it was intended when this code was implemented, more than 20 years ago. I agree it might not be desirable anymore, so while this behavior is certainly not a bug, changing it is a feature request that we should consider. Thanks!
            balta Tadas BalaiĊĦis added a comment -

            Or you may do it as Oracle did: don't allow to drop user if there is a connected session.

            balta Tadas BalaiĊĦis added a comment - Or you may do it as Oracle did: don't allow to drop user if there is a connected session.
            serg Sergei Golubchik added a comment -

            Yes, thanks, indeed. So either kill them all or refuse to drop. Or wait until they all disconnect.

            serg Sergei Golubchik added a comment - Yes, thanks, indeed. So either kill them all or refuse to drop. Or wait until they all disconnect.
            sanja Oleksandr Byelkin added a comment - - edited

            I think forcing user out is correct behavior (we have kill and it can be used here), i.e. current command can be killed (or finished and connection closed)

            sanja Oleksandr Byelkin added a comment - - edited I think forcing user out is correct behavior (we have kill and it can be used here), i.e. current command can be killed (or finished and connection closed)
            sanja Oleksandr Byelkin added a comment - - edited

            Actually forcing user will need detection so we can add special parameter like FORCE to trigger it (for safety).

            I.e. normally DROP USER issue an error if user present and with the parameter kill the connection (or many connections) of the user.

            sanja Oleksandr Byelkin added a comment - - edited Actually forcing user will need detection so we can add special parameter like FORCE to trigger it (for safety). I.e. normally DROP USER issue an error if user present and with the parameter kill the connection (or many connections) of the user.
            serg Sergei Golubchik added a comment -

            Another approach:

            • DROP USER waits
            • DROP USER ... FORCE kills
            • perhaps DROP USER ... NOWAIT too?
            serg Sergei Golubchik added a comment - Another approach: DROP USER waits DROP USER ... FORCE kills perhaps DROP USER ... NOWAIT too?
            serg Sergei Golubchik added a comment -

            See https://mariadb.org/tell-us-how-to-drop-user/

            serg Sergei Golubchik added a comment - See https://mariadb.org/tell-us-how-to-drop-user/

            People

              shulga Dmitry Shulga
              balta Tadas BalaiĊĦis
              Votes:
              1 Vote for this issue
              Watchers:
              6 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.