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

inconsistent check_access()

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.0.4, 5.1.67, 5.2.14, 5.3.12, 5.5.33a
    • 10.6
    • None
    • None

    Description

      The check_access() function retrieves privileges like that

              db_access= acl_get(sctx->host, sctx->ip, sctx->priv_user, db,
      		 
                                 db_is_pattern);

      Note that it is using sctx->host and sctx->priv_user pair. This is wrong, they belong to different values — the first is the host part in the USER(), the second is the user part in CURRENT_USER().

      See the following test case:

      create user c@localhost;
      		 
      create user c@'%';
      		 
      grant select on mysql.* to c@'%';
      		 
      connect (c,localhost,c,,,,,);
      		 
      select user(), current_user();
      		 
      select user from mysql.user group by user;
      		 
      disconnect c;
      		 
      connection default;
      		 
      drop user c@'%';
      		 
      drop user c@localhost;

      Note that SELECT is allowed, while it is granted to c@%, and we're connected as c@localhost. Which suggests wildcard matching for the purpose of privilege checking. On the other hand, if the test case above is modified as

      create user ''@localhost;
      		 
      create user c@'%';
      		 
      grant select on mysql.* to c@'%';
      		 
      connect (c,localhost,c,,,,,);
      		 
      select user(), current_user();
      		 
      --error ER_TABLEACCESS_DENIED_ERROR
      		 
      select user from mysql.user group by user;
      		 
      disconnect c;
      		 
      connection default;
      		 
      drop user c@'%';
      		 
      drop user ''@localhost;

      then the SELECT will fail. De facto, wildcard matching works for host names, but not for user names. Which is inconsistent.

      Note: if this is to be fixed, all privilege checks should be analyzed and probably changed, including the one for SET ROLE

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-5232 SET ROLE checks privileges differently from check_access()

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            serg Sergei Golubchik created issue -
            serg Sergei Golubchik made changes -
            Field Original Value New Value
            serg Sergei Golubchik made changes -
            Description The {{check_access()}} function retrieves privileges like that
            {code}
                    db_access= acl_get(sctx->host, sctx->ip, sctx->priv_user, db,
                                       db_is_pattern);
            {code}

            Note that it is using {{sctx->host}} and {{sctx->priv_user}} pair. This is wrong, they belong to different values — the first is the host part in the {{USER()}}, the second is the user part in {{CURRENT_USER()}}.

            Which means, the following {{SELECT}} is allowed, while it shouldn't be:
            		 The {{check_access()}} function retrieves privileges like that
            {code}
                    db_access= acl_get(sctx->host, sctx->ip, sctx->priv_user, db,
                                       db_is_pattern);
            {code}

            Note that it is using {{sctx->host}} and {{sctx->priv_user}} pair. This is wrong, they belong to different values — the first is the host part in the {{USER()}}, the second is the user part in {{CURRENT_USER()}}.

            See the following test case:
            {code:sql}
            create user c@localhost;
            create user c;
            grant select on mysql.* to c;
            connect (c,localhost,c,,,,,);
            select user(), current_user();
            select user from mysql.user group by user;
            disconnect c;
            connection default;
            drop user c;
            drop user c@localhost;
            {code}
            Note that {{SELECT}} is allowed, while it is granted to {{c@%}}, and we're connected as {{c@localhost}}. Which suggests wildcard matching for the purpose of privilege checking. On the other hand, if the test case above is modified as
            {code:sql}
            create user ''@localhost;
            create user c;
            grant select on mysql.* to c;
            connect (c,localhost,c,,,,,);
            select user(), current_user();
            --error ER_TABLEACCESS_DENIED_ERROR
            select user from mysql.user group by user;
            disconnect c;
            connection default;
            drop user c;
            drop user ''@localhost;
            {code}
            then the {{SELECT}} will fail. De facto, wildcard matching works for host names, but not for user names. Which is inconsistent.

            _Note: if this is to be fixed, all privilege checks should be analyzed and probably changed, including the one for {{SET ROLE}}_
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.7 [ 14100 ]
            Fix Version/s 10.0.6 [ 13202 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.8 [ 14200 ]
            Fix Version/s 10.0.7 [ 14100 ]
            serg Sergei Golubchik made changes -
            Description The {{check_access()}} function retrieves privileges like that
            {code}
                    db_access= acl_get(sctx->host, sctx->ip, sctx->priv_user, db,
                                       db_is_pattern);
            {code}

            Note that it is using {{sctx->host}} and {{sctx->priv_user}} pair. This is wrong, they belong to different values — the first is the host part in the {{USER()}}, the second is the user part in {{CURRENT_USER()}}.

            See the following test case:
            {code:sql}
            create user c@localhost;
            create user c;
            grant select on mysql.* to c;
            connect (c,localhost,c,,,,,);
            select user(), current_user();
            select user from mysql.user group by user;
            disconnect c;
            connection default;
            drop user c;
            drop user c@localhost;
            {code}
            Note that {{SELECT}} is allowed, while it is granted to {{c@%}}, and we're connected as {{c@localhost}}. Which suggests wildcard matching for the purpose of privilege checking. On the other hand, if the test case above is modified as
            {code:sql}
            create user ''@localhost;
            create user c;
            grant select on mysql.* to c;
            connect (c,localhost,c,,,,,);
            select user(), current_user();
            --error ER_TABLEACCESS_DENIED_ERROR
            select user from mysql.user group by user;
            disconnect c;
            connection default;
            drop user c;
            drop user ''@localhost;
            {code}
            then the {{SELECT}} will fail. De facto, wildcard matching works for host names, but not for user names. Which is inconsistent.

            _Note: if this is to be fixed, all privilege checks should be analyzed and probably changed, including the one for {{SET ROLE}}_             		The {{check_access()}} function retrieves privileges like that
            {code}
                    db_access= acl_get(sctx->host, sctx->ip, sctx->priv_user, db,
                                       db_is_pattern);
            {code}

            Note that it is using {{sctx->host}} and {{sctx->priv_user}} pair. This is wrong, they belong to different values — the first is the host part in the {{USER()}}, the second is the user part in {{CURRENT_USER()}}.

            See the following test case:
            {code:sql}
            create user c@localhost;
            create user c@'%';
            grant select on mysql.* to c@'%';
            connect (c,localhost,c,,,,,);
            select user(), current_user();
            select user from mysql.user group by user;
            disconnect c;
            connection default;
            drop user c@'%';
            drop user c@localhost;
            {code}
            Note that {{SELECT}} is allowed, while it is granted to {{c@%}}, and we're connected as {{c@localhost}}. Which suggests wildcard matching for the purpose of privilege checking. On the other hand, if the test case above is modified as
            {code:sql}
            create user ''@localhost;
            create user c;
            grant select on mysql.* to c;
            connect (c,localhost,c,,,,,);
            select user(), current_user();
            --error ER_TABLEACCESS_DENIED_ERROR
            select user from mysql.user group by user;
            disconnect c;
            connection default;
            drop user c;
            drop user ''@localhost;
            {code}
            then the {{SELECT}} will fail. De facto, wildcard matching works for host names, but not for user names. Which is inconsistent.

            _Note: if this is to be fixed, all privilege checks should be analyzed and probably changed, including the one for {{SET ROLE}}_
            serg Sergei Golubchik made changes -
            Description The {{check_access()}} function retrieves privileges like that
            {code}
                    db_access= acl_get(sctx->host, sctx->ip, sctx->priv_user, db,
                                       db_is_pattern);
            {code}

            Note that it is using {{sctx->host}} and {{sctx->priv_user}} pair. This is wrong, they belong to different values — the first is the host part in the {{USER()}}, the second is the user part in {{CURRENT_USER()}}.

            See the following test case:
            {code:sql}
            create user c@localhost;
            create user c@'%';
            grant select on mysql.* to c@'%';
            connect (c,localhost,c,,,,,);
            select user(), current_user();
            select user from mysql.user group by user;
            disconnect c;
            connection default;
            drop user c@'%';
            drop user c@localhost;
            {code}
            Note that {{SELECT}} is allowed, while it is granted to {{c@%}}, and we're connected as {{c@localhost}}. Which suggests wildcard matching for the purpose of privilege checking. On the other hand, if the test case above is modified as
            {code:sql}
            create user ''@localhost;
            create user c;
            grant select on mysql.* to c;
            connect (c,localhost,c,,,,,);
            select user(), current_user();
            --error ER_TABLEACCESS_DENIED_ERROR
            select user from mysql.user group by user;
            disconnect c;
            connection default;
            drop user c;
            drop user ''@localhost;
            {code}
            then the {{SELECT}} will fail. De facto, wildcard matching works for host names, but not for user names. Which is inconsistent.

            _Note: if this is to be fixed, all privilege checks should be analyzed and probably changed, including the one for {{SET ROLE}}_             		The {{check_access()}} function retrieves privileges like that
            {code}
                    db_access= acl_get(sctx->host, sctx->ip, sctx->priv_user, db,
                                       db_is_pattern);
            {code}

            Note that it is using {{sctx->host}} and {{sctx->priv_user}} pair. This is wrong, they belong to different values — the first is the host part in the {{USER()}}, the second is the user part in {{CURRENT_USER()}}.

            See the following test case:
            {code:sql}
            create user c@localhost;
            create user c@'%';
            grant select on mysql.* to c@'%';
            connect (c,localhost,c,,,,,);
            select user(), current_user();
            select user from mysql.user group by user;
            disconnect c;
            connection default;
            drop user c@'%';
            drop user c@localhost;
            {code}
            Note that {{SELECT}} is allowed, while it is granted to {{c@%}}, and we're connected as {{c@localhost}}. Which suggests wildcard matching for the purpose of privilege checking. On the other hand, if the test case above is modified as
            {code:sql}
            create user ''@localhost;
            create user c@'%';
            grant select on mysql.* to c@'%';
            connect (c,localhost,c,,,,,);
            select user(), current_user();
            --error ER_TABLEACCESS_DENIED_ERROR
            select user from mysql.user group by user;
            disconnect c;
            connection default;
            drop user c@'%';
            drop user ''@localhost;
            {code}
            then the {{SELECT}} will fail. De facto, wildcard matching works for host names, but not for user names. Which is inconsistent.

            _Note: if this is to be fixed, all privilege checks should be analyzed and probably changed, including the one for {{SET ROLE}}_
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.9 [ 14400 ]
            Fix Version/s 10.0.8 [ 14200 ]
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.1.0 [ 12200 ]
            Fix Version/s 10.0.9 [ 14400 ]
            serg Sergei Golubchik made changes -
            Workflow defaullt [ 29601 ] MariaDB v2 [ 45025 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.1 [ 16100 ]
            Fix Version/s 10.1.0 [ 12200 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Workflow MariaDB v2 [ 45025 ] MariaDB v3 [ 65556 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.2 [ 14601 ]
            Fix Version/s 10.1 [ 16100 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.2 [ 14601 ]
            elenst Elena Stepanova made changes -
            Fix Version/s 5.5 [ 15800 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.4 [ 22408 ]
            Fix Version/s 5.5 [ 15800 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.6 [ 24028 ]
            Fix Version/s 10.4 [ 22408 ]
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 65556 ] MariaDB v4 [ 139556 ]

            People

              serg Sergei Golubchik
              serg Sergei Golubchik
              Votes:
              0 Vote for this issue
              Watchers:
              1 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.