Uploaded image for project: 'MariaDB MaxScale'
  1. MariaDB MaxScale
  2. MXS-1078

Refactor dbusers.c



    • Task
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • 2.1.0
    • 2.2.0
    • mariadbbackend
    • None
    • 2017-27


      Background: When a client connects to MaxScale, he's authorized by comparing his username, host, password etc to the values in the user database (dbusers.c). The database is filled with user accounts using backend data, when MaxScale starts. The host-field in the userdb can have various forms: IP-address, host name (text), or a wildcard form of one of the former. If possible, host names are converted to IP-addresses when read. If the host name contains wildcards, this is impossible. This is why host names with wildcards were not allowed previously by MaxScale, although they are allowed by the sql-server. A recent commit added support for these to MaxScale aswell, but the implementation is unoptimal.

      The problem: Currently, the various ways of finding the correct user@host-combination from the userDB-hashmap have been integrated into the hashmap itself through its function pointers (cmpfun). To match wildcard hostnames, a query needs to be made since the client ip-address needs to be converted to a text-form host name. This is very slow compared to any typical hashmap operations, and will also keep the map read-locked for some while. Also, this type of logic shouldn't really be inside the container's own functions.

      Goal: Take the logic out of the hashmap and only use short and simple hash- and compare-functions inside the hashmap. The element type should be changed to a list/array that contains the username once and then all the possible hostname (IP or text) and password combinations for that user. The hashmap only handles these elements as a whole, the details are taken care of by other functions.

      How: Here's some ideas.
      1. Use only username as hash key, use inbuilt string hashing (hashtable_item_strhash).

      2. The element type should be like

      • MySQL hashtable entry. The entry contains the username (used for hashing as it
      • contains no wildcards) and a list of possible hosts for that user. The hosts
      • are divided to resolved hosts and hosts with wildcards.
        typedef struct mysql_user_table_entry { char *user_name; MYSQL_USER_HOST *fq_hosts; MYSQL_USER_HOST *wc_hosts; int lock; anything else? }


      3. Remove multiple lookups of the map in gw_find_mysql_user_password_sha1. Do just one lookup and then check the different hosts. May have to lock the table entry while doing it. Requires modifying all hashtable-related functions.


        Issue Links



              markus makela markus makela
              esa.korhonen Esa Korhonen
              0 Vote for this issue
              2 Start watching this issue



                Git Integration

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