MySQL
  Home arrow MySQL arrow Page 2 - The MySQL Grant Tables
Dev Shed Forums  
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Smartphone Development  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Mobile Linux  
App Generation ROI  
IBM® developerWorks  
Forums Sitemap  
E-Commerce Hosting  
Linux Web Hosting  
Managed Hosting  
Small Business Hosting  
VPS Hosting  
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid  
Request Media Kit
Contact Us  
Site Map  
Privacy Policy  
Support  
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
Google.com  
MYSQL

The MySQL Grant Tables
By: W.J. Gilmore
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: starstarstarstarstar / 17
    1999-03-01


    Table of Contents:
  • The MySQL Grant Tables
  • Access Control
  • Tables_priv and columns_priv
  • References

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      error-file:tidyout.log Del.ici.ous error-file:tidyout.log Digg
      error-file:tidyout.log Blink error-file:tidyout.log Simpy
      error-file:tidyout.log Google error-file:tidyout.log Spurl
      error-file:tidyout.log Y! MyWeb error-file:tidyout.log Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article

     
     
    ADVERTISEMENT


    The MySQL Grant Tables - Access Control
    ( Page 2 of 4 )

    The process in which the MySQL server controls user privileges, although seemingly daunting at first look, is actually a fairly simple, although secure, procedure. Let's take a look at some not-so-obvious properties of this process before working through an example.

    Property#1:
    The tables can be looked at as a sort of filter which works from most general to most specific. This filter, (working from general to specific), is as follows:

    • User table.
    • Db Table
    • Host Table
    • Tables_priv Table
    • Columns_priv Table

    Property#2:
    Once a server-connection is made, there are two kinds of requests that a user can make:

    • Administrative Request (shutdown, reload, process, etc...)
    • Database-related Request (insert, delete, alter, update, etc...)

    When a user makes an administrative request, the server only has to look in one specific location: the user table. This is because the user table is the only table containing privileges related to administrative processes. However, when the user makes a database request, the process is a slight bit more complicated.

    You may have noticed that the grant tables are somewhat redundant (i.e. A 'select' privilege within the user table, and the same privilege repeated within the host and user tables); This is not without reason. One could consider the database-related privileges within the user table as global. That is, the privileges granted to the user within this table are good for every database on the server. These privileges could be considered superuser privileges. On the other hand, the database-related privileges contained within the host and db tables are specifically related to the host or database in question. Thus it would be a wise decision to leave all privileges within this table as 'N'.

    Regardless of you decide to set the user table, please take note of the following example. Let's assume our user and db tables are as follows:

    User Table
    Host %.pi.com
    User wj
    Password 34ghyT
    Select_priv 'N'
    Insert_priv 'Y'
    Update_priv 'N'
    Delete_priv 'N'
    Index_priv 'N'
    Alter_priv 'N'
    Create_priv 'N'
    Drop_priv 'N'
    Grant_priv 'N'
    Reload_priv 'N'
    Shutdown_priv 'N'
    Process_priv 'N'
    File_priv 'N'
     
    Db Table
    Host %.pi.com
    Db oats
    User wj
    Select_priv 'Y'
    Insert_priv 'Y'
    Update_priv 'Y'
    Delete_priv 'N'
    Index_priv 'N'
    Alter_priv 'N'
    Create_priv 'N'
    Drop_priv 'N'
    Grant_priv 'Y'

    Scenario #1: Failed Connection Attempt

    1. User 'alessia' connection attempt failed. - Host, User and/or password does not match up with those contained within the user table. User is denied access.

    Scenario #2: 'N' db-privilege in user table, 'Y' db-privilege in db table.

    1. User 'wj' connection attempt successful.
    2. User 'wj' attempts to perform a 'Select' command on the 'oats' database.
    3. Server looks towards the user table. There is a 'N' (denied) entry for the 'Select' command.
    4. Server then looks toward the db table. There is a 'Y' (allowed) entry for the 'Select' command.
    5. Request is successful, because there is a 'Y' within the SELECT column of the user's db table insertion.

    Scenario #3: 'Y' db-privilege in user table, 'N' db-privilege in db table.

    1. User 'wj' connection attempt successful.
    2. User 'wj' attempts to perform a 'Select' command on the 'oats' database.
    3. Server looks towards the user table. There is a 'Y' (allowed) entry for the 'Select' command. Since the privileges granted within the user table are global, the request is successfully carried out.

    Scenario #4: 'N' db-privilege in user table, 'N' db-privilege in db table.

    1. User 'wj' connection attempt successful.
    2. User 'wj' attempts to perform a 'Select' command on the 'oats' database.
    3. Server looks towards the user table. There is a 'N' (denied) entry for the 'Select' command.
    4. Server now looks towards the db table. There is a 'N' (denied= entry for the 'Select' command.
    5. Server now looks towards the tables_priv and columns_priv tables. If the privileges are in accordance with the user's request, access is granted. Otherwise, access is denied.
    The tables_privand columns_priv tables are discussed in further detail later on in this article.

    Scenario #5: Let's assume the following is true:

    • The 'host' column for user'wj' is '%' within the user table.
    • the 'host' column for user 'wj' was blank within the db table.
    What happens?
    1. User 'wj' connection via a given host is attempted.
    2. Assuming the password is correct, the attempt is successful, because the user table states that any ('%') host can connect if the connection is via username 'wj' and the given password.
    3. The MySQL server looks to the db table. However, there is no host given.
    4. The MySQL server now looks to the host table. IF the db in which the user is connecting to is listed within the host table along with the particular host name that the user is connecting from, then the user is free to carry out commands in accordance with the privileges listed within the host table. If the db/host are not in accordance with those in which the user is connecting from, the user cannot carry out commands and is in essence denied of connection.

    The above scenarios should give the reader at least a bit of insight into the privilege system. We will now move on to the latest additions to the privilege system, the tables_priv and columns_priv tables.



     
     
    >>> More MySQL Articles          >>> More By W.J. Gilmore
     

       

    MYSQL ARTICLES

    - MySQL Security Tips
    - Designing a MySQL Database: Tips and Techniq...
    - The Three Most Important MySQL Queries
    - Null and Empty Strings
    - MySQL Server Tuning Tips and Tricks
    - MySQL Query Optimizations and Schema Design
    - MySQL Benchmarking Tools and Utilities
    - MySQL Benchmarking Concepts and Strategies
    - Take Some Load off MySQL with MemCached
    - MySQL Table Prefix Changer Tool in PHP
    - Using the SIGNAL Statement for Error Handling
    - Error Handling Examples
    - Error Handling
    - Completing a Search Engine with MySQL and PH...
    - Paginating Result Sets for a Search Engine B...





    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 4 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek