Pro MySQL experts voice in open source phần 8 ppt

Granting All Privileges When you want to grant or revoke all available privileges for a user (except for the GRANT ➥ OPTION privilege) at a specific privilege scope level, you can substitute the keyword ALL for the (much longer and cumbersome) list of privileges. For instance, if you wanted to provide mkruck@localhost all privileges on the ToyStore.Customer table, you could issue the following: GRANT ALL ON ToyStore.Customer TO 'mkruck'@'localhost'; This would affect all table-level privileges: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, and ALTER. Issuing GRANT ALL requests at other scope levels yields similar results. Consider this example: GRANT ALL ON ToyStore.* TO 'mkruck'@'admin.example.com'; This would grant the user account mkruck@admin.example.com the database-level privileges of ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES, CREATE VIEW, DELETE, DROP, EXECUTE, INSERT, UPDATE, INDEX, SELECT, SHOW VIEW, and LOCK TABLES. By using the *.* modifier, you grant the user every privilege except the GRANT OPTION privilege, so take care when using the ALL keyword to use the correct scope modifier after the ON keyword! To revoke all privileges issued to a user account, use the REVOKE ALL command: REVOKE ALL ON *.* FROM 'mkruck'@'localhost'; This would remove all global privileges from mkruck@localhost except for the GRANT OPTION privilege. To include the GRANT OPTION privilege in the REVOKE command, issue the following version: REVOKE ALL, GRANT OPTION ON *.* FROM 'mkruck'@'localhost'; This syntax is available from MySQL 4.1.2. Prior to this version, two statements are neces- sary to remove all privileges for a user: REVOKE ALL ON *.* FROM 'mkruck'@'localhost'; REVOKE GRANT OPTION ON *.* FROM 'mkruck'@'localhost'; Viewing User Privileges You can use a number of methods to obtain information regarding a user’s granted or revoked privileges. Which method you choose is a really just a matter of formatting preference. Here, we’ll cover using the SHOW GRANTS command and querying the grant tables directly. Another method of viewing user privileges is to use the new support for the INFORMATION_SCHEMA virtual database, which we’ll cover in Chapter 21. Using SHOW GRANTS One way to check a user’s grants is to use the SHOW GRANTS statement: SHOW GRANTS FOR username; CHAPTER 15 ■ USER ADMINISTRATION 507 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 507 This will show, in reproducible GRANT statements, the privileges available to the user (helpful in reminding you of the syntax for the GRANT statement). Listing 15-2 shows the output of SHOW GRANTS. Listing 15-2. SHOWS GRANTS Output mysql> SHOW GRANTS FOR 'jpipes'@'localhost'; + + | Grants for jpipes@localhost | + + | GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'jpipes'@'localhost' | | GRANT SELECT ON `ToyStore`.* TO 'jpipes'@'localhost' | | GRANT EXECUTE ON `test`.`ShowIndexSelectivity` TO 'jpipes'@'localhost' | + + 3 rows in set (0.00 sec) You may notice a peculiarity in the results in Listing 15-2. The privileges for jpipes@localhost on a global level completely negate the need for the SELECT privilege on the ToyStore database. So, why do both lines appear? This is because MySQL does not remove grant table entries just because a more encompassing privilege level has been granted to the user. Keep this in mind when changing user privileges. If at some point, you loosen a user’s restrictions by granting global privileges, and later revoke the global privileges, the database- specific privileges will still exist. Querying the Grant Tables Another option for determining a user’s privileges involves querying the actual grant tables (which are described in the next section). To see global permissions for jpipes@localhost, query the user grant table, as Listing 15-3 demonstrates. Listing 15-3. Querying the user Grant Table Directly mysql> SELECT * FROM mysql.user -> WHERE User = 'jpipes' AND Host = 'localhost' \G *************************** 1. row *************************** Host: localhost User: jpipes Password: Select_priv: Y Insert_priv: Y Update_priv: Y Delete_priv: Y Create_priv: N Drop_priv: N Reload_priv: N Shutdown_priv: N Process_priv: N File_priv: N CHAPTER 15 ■ USER ADMINISTRATION508 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 508 Grant_priv: N References_priv: N Index_priv: N Alter_priv: N Show_db_priv: N Super_priv: N Create_tmp_table_priv: N Lock_tables_priv: N Execute_priv: N Repl_slave_priv: N Repl_client_priv: N Create_view_priv: N Show_view_priv: N Create_routine_priv: N Alter_routine_priv: N Create_user_priv: N ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 1 row in set (0.31 sec) Here, you can see all privileges except the SELECT, INSERT, UPDATE, and DELETE privileges are set to N, which makes sense; the first line from the previous output of Listing 15-2 shows the global GRANT statement having these privileges enabled. Querying each of the grant tables as in Listing 15-3 will produce similar output for each of the privilege scope levels. The user and db tables store privilege information in separate fields of type ENUM('Y','N'). The tables_priv, columns_priv, and procs_priv grant tables store privi- lege information in a single SET() field containing a list of the available privileges. Listing 15-4 shows the output of a SELECT on the tables_priv table to illustrate this difference. Listing 15-4. Querying the columns_priv Grant Table Directly mysql> SELECT Db, Table_name, Table_priv FROM mysql.tables_priv -> WHERE User = 'mkruck' AND Host = 'localhost'; + + + + | Db | Table_name | Table_priv | + + + + | ToyStore | Customer | Select,Insert | + + + + 1 row in set (0.00 sec) Now that you’ve seen how to grant and revoke privileges, it’s important to understand how MySQL actually applies and verifies those privileges. CHAPTER 15 ■ USER ADMINISTRATION 509 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 509 How MySQL Controls Access and Verifies Privileges MySQL controls access to the database server through a two-step process. In the first step of the process, MySQL identifies and authenticates the user connecting through a MySQL client. The second part of the process entails determining what the authenticated user can do once inside the system, based on that user’s privileges. Figure 15-1 illustrates the flow of events in the MySQL access control and privilege verifi- cation system. You can see how the different steps of the process are designed to ensure that the requests issued by the client, including the actual connection request, are allowed. When requests or connections do not meet all access criteria, MySQL returns an error code corre- sponding to the reason for request refusal. w of events Supplies: [host] [username] [password] Client requests connection MySQL refuses connection Credentials not valid MySQL verifies supplied credentials MySQL validates the host, user, and password by querying the user grant table Client issues statement Credentials valid e.g., SELECT, INSERT, ALTER TABLE, etc. Step 1: Access Authentication Step 2: Permission Verfiication MySQL determines permissions needed for requested statement Some requests need multiple permissions; for example, an ALTER TABLE request requires permission for ALTER, INSERT, and CREATE privileges for the table MySQL looks for needed permission to objects in grant tables matching the user/ host MySQL queries the db, tables_priv, and columns_priv grant tables for appropriate permissions MySQL refuses request Privileges not matched All privileges found MySQL sends request along to parser CHAPTER 15 ■ USER ADMINISTRATION510 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 510 ■Note See http://dev.mysql.com/doc/mysql/en/Access_denied.html for an explanation of com- mon reasons for access denied messages. How MySQL Authenticates Users MySQL uses a two-part label to identify the user issuing a connection request. This label is composed of the username and the host values. The host value represents the machine from which the connection originates. The username part of the label is the specific user connect- ing from the host. The user grant table stores information needed to authenticate incoming connections, along with a set of global privileges tied to each entry in the table (discussed earlier in the chap- ter). The three columns of the user grant table that are used in the connection authentication decision are Host, User, and Password. The User column value can be either an actual username (for example, joe_smith) or a blank string (' '). Wildcard matches can be used in the Host col- umn. An underscore (_) character represents a single character, and a percent (%) represents any number of characters. The Host column value can be in any of the following formats: •Host (or domain) name: www.mycompany.com, %.mycompany.com •Host IP address: 123.124.125.255, 123.124.125.% • Local machine client: localhost, and on some Linux systems, localhost.localdomain MySQL compares the username and host values of the connection with entries in the user grant table in a special way. When the mysql.user table data is loaded into memory, it is first sorted based on how specific the User and Host column values are. Because the Host col- umn values can contain wildcard characters, and the User column can be blank (meaning any user at the specified Host), some table entries will be more specific than others. For example, Listing 15-5 shows some sample rows from the user grant table on a test database server we’ve set up for the examples in this chapter. Listing 15-5. The user Grant Table mysql> SELECT User, Host FROM mysql.user; + + + | User | Host | + + + | | % | | mkruck | % | | jpipes | %.example.com | | mkruck | admin.example.com | | | localhost | | jpipes | localhost | | mkruck | localhost | | root | localhost | | responder | mail.example.com | + + + CHAPTER 15 ■ USER ADMINISTRATION 511 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 511 When MySQL sorts this list according to specificity, it will be ordered by the most specific Host value to the least specific. Since IP addresses or domain names are more specific than a host specification that contains a wildcard, the actual order in which MySQL would see the entries in Listing 15-5 would be as listed in Table 15-6. Table 15-6. The user Table Results Ordered by Specificity of Username and Host Label User Host jpipes localhost jpipes %.example.com mkruck localhost mkruck admin.example.com mkruck % responder mail.example.com root localhost localhost % If the label jpipes@groups.example.com were passed to the identification system, MySQL would first search for all entries matching the supplied username or having a blank entry in the User column. Then it would go down the returned list of entries, looking first for a Host column value that matches the incoming tag. Four entries in the sample user grant table match this username part of the identification label, as shown in Table 15-7. Table 15-7. Possible Entries That Could Match Label jpipes@groups.example.com User Host jpipes localhost jpipes %.example.com localhost % Of these four, the top row contains the most specific username and host combination. However, the groups.example.com domain clearly does not match the Host column value localhost. The next row, with the Host value of %.example.com matches our supplied domain, and so this row is used in order to determine access and privileges to the system. If the Host value did not match, the next row would be checked, and so on down the line. We cover this sorting logic here because of the confusion some MySQL users experience regarding why certain privileges have not been granted to them when executing queries. This confusion can be tracked to a misunderstanding of which entry in the user grant table has been loaded for their current connection. Often, if a number of entries have been made to the user grant table with similar Host and User column values, it may not be clear which entry has been loaded. If you are unsure about which entry has been loaded for a connection, use the CURRENT_USER() function, as shown in Listing 15-6. CHAPTER 15 ■ USER ADMINISTRATION512 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 512 Listing 15-6. Using the CURRENT_USER() Function to Determine Active Entry mysql> SELECT CURRENT_USER(); + + | CURRENT_USER() | + + | root@localhost | + + 1 row in set (0.00 sec) DEFAULT CONNECTION PARAMETERS Clients can connect to a MySQL server in numerous ways. Regardless of the client or API used to connect, MySQL executes the same authentication procedures to authorize the incoming requests. Even so, it is possi- ble through the use of option files, to configure clients to send a default host, username, and password along with each connection. This is done by altering the MySQL configuration file (described in Chapter 14) and inserting one or more of the following entries under the [client] configuration section: • host=hostname • user=username • password=your_pass Setting a default password for the MySQL client is not a secure practice, and should not be done on anything but test or development servers that do not have any sensitive data. Also be aware that, by default, MySQL accepts connections from anonymous users; that is, MySQL allows connections that do not supply a username. Though the default access of this anonymous user is lim- ited, and only the test database can be accessed, it is still a security threat, as discussed in Chapter 16. How MySQL Verifies User Privileges After MySQL has verified that the user connecting has access to the database server, the next step in the access control process is to determine what, if anything, that user may do while connected to the server. In order to determine if a user can issue a command, the privileges at the different scope levels are checked from the broadest scope (global) to the finest scope (column level). An additional grant table, mysql.host, is consulted in special circumstances. Logically, MySQL follows this equation to determine if a user has appropriate privileges to a database-specific object: •Global privileges • Or (database privileges and host privileges) • Or table privileges • Or column privileges CHAPTER 15 ■ USER ADMINISTRATION 513 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 513 Take a look at Figure 15-2 to get a feel for how this logic is processed by the privilege veri- fication system for a simple request. In Figure 15-2, let’s assume that the connection was authenticated as jpipes@localhost, and sent the following request: SELECT login, password FROM ToyStore.Customer WHERE ID=1; MySQL would first look to see if an entry existed in the user grant table matching the supplied user and host and having the SELECT privilege enabled (found in the select_priv column). If the value of the SELECT privilege were 'Y', MySQL would stop the privilege verification process and continue with the request’s execution. If the value of the SELECT privilege were 'N', MySQL would continue down the grant table chain to the db table. Figure 15-2. Privilege verification detailed flow of events MySQL determines which privilege(s) and scope are required MySQL accepts request Yes Row exists for: db.User='jpipes' AND (db.Host='localhost' OR db.Host=") AND db.Db='ToyStore'? Required privilege: SELECT Database: ToyStore Table: Customer Columns: login, password MySQL accepts request Row exists in host table for: host.Db='ToyStore' AND host.Host='localhost' ? MySQL denies request db.Select_priv = 'Y' AND host.Select_priv = 'Y' ? MySQL accepts request Yes Row exists in tables_priv table for: tables_priv.User='jpipes' AND tables_priv.Host='localhost' AND tables_priv.Db='ToyStore' AND FIND_IN_SET('SELECT', tables_priv.table_priv)>0 ? MySQL accepts request Client request received and connection authorized (see Figure 15-1) Rows exists in user table for: user.User='jpipes' AND user.Host='localhost' AND user.Select_priv='Y' ? MySQL denies request Row exists in db table for: db.User='jpipes' AND db.Host='localhost' AND db.Db='ToyStore' ? db.Select_priv = 'Y' ? Two rows exists in columns_priv table for: columns_priv.User='jpipes' AND columns_priv.Host='localhost' AND columns_priv.Db='ToyStore' AND columns_priv.Table_name='Customer' AND columns_priv.Column_name IN ('login','password') FIND_IN_SET('SELECT', columns_priv.column_priv)>0 MySQL accepts request MySQL denies request NoYes Assume query: SELECT login, password FROM ToyStore.Customer WHERE customer_id=1 No No No Yes Yes Yes No No No Yes No AND CHAPTER 15 ■ USER ADMINISTRATION514 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 514 MySQL looks for an entry in the db table matching db.User='jpipes' AND ➥ db.Host='localhost' AND db.Database_name='ToyStore'. If a row exists in mysql.db for this combination, the db.Select_priv column is checked. If it found a 'Y' value for the db.Select_priv column, MySQL would accept the request. If a row did not exist in mysql.db matching db.User='jpipes' AND db.Host='localhost' AND db.Database_name='ToyStore' but a row that matched db.User='jpipes' AND db.Host='' AND db.Database_name='ToyStore' did exist, then the mysql.host grant table is queried. If no rows in mysql.host match host.Host='localhost' AND host.Db='ToyStore', MySQL denies the request. If a row in mysql.host does match host.Host='localhost' AND ➥ host.Db='ToyStore', then the Select_priv column in both rows in mysql.db and mysql.host are checked for a 'Y' value. If this is the case, MySQL accepts the request. (We’ll discuss the relationship between the db and host grant tables in just a moment.) If not, MySQL continues to the tables_priv grant table. If MySQL has reached the tables_priv grant table, it determines if there is a row in the table that matches the condition WHERE User='jpipes' AND Host='localhost' AND Db='ToyStore' AND Table_name='Customer' AND FIND_IN_SET('SELECT', Table_priv)>0. 2 If such a row exists, MySQL accepts the request. If not, it repeats a similar process in the columns_priv grant table. If MySQL does not find rows in the columns_priv table for the requested columns of the SELECT statement, MySQL denies the request. The Purpose of the host Grant Table The host grant table stores entries that are used when the db grant table does not have ade- quate information to process the privilege verification request (see Figure 15-2). Neither the GRANT nor REVOKE statements affect entries in mysql.host. Entries must be added and removed manually. The host grant table has an almost identical schema to the db grant table, except it does not have a User column. When a statement request is evaluated by the access control system, and it comes to the database grant level (meaning the user’s global privileges were insufficient to grant the request and the object requiring privileges is of a database scope level or below), the access control system checks to see if there is an entry in mysql.db for the supplied user. If one is found, and the Host column value is blank (not '%', which means any database) then mysql.host is consulted for further information. If an entry is found in mysql.host for the sup- plied Host value in the identification label, then the privileges contained in both mysql.db and mysql.host are combined (with a logical AND expression) to determine if the request should be granted. So, why would you even bother using the host table? That’s a good question. Most data- base administrators never even touch it. Many don’t even know it exists, and if they do, they don’t know why it’s there. The primary reason that mysql.host was added to the grant table mix was to provide database administrators the ability to grant or deny access requests com- ing from certain hosts or domains, regardless of the username. Remember that the MySQL access control system is not denial-based. It uses an OR-based system to search for any granted level of needed privilege, instead of searching first for the explicit denial of that privilege. CHAPTER 15 ■ USER ADMINISTRATION 515 2. MySQL doesn’t actually use the FIND_IN_SET() function, but rather does a bitwise & operation on the privileges loaded into memory for the queried user. We use the FIND_IN_SET() function here to demonstrate the concept. 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 515 However, there are times when it is necessary to create what are known as stop lists, or lists of items to which access specifically is denied. mysql.host can be used to create just such lists for domains, regardless of the user part of the identification label. Let’s say we have three server hosts in our network: sales.example.com, intranet.example.com, and public.example.com. Of these, the only server that we don’t want to have access to any databases is public.example.com, as it poses a security risk. So, we run the following code: mysql> INSERT INTO mysql.host SET Host='public.example.com', Db='%'; mysql> INSERT INTO mysql.host SET Host='%.example.com', Db='%' -> , Select_priv='Y', Insert_priv='Y', Update_priv='Y', Delete_priv='Y' -> , Create_priv='Y', Drop_priv='Y', Index_priv='Y',Alter_priv='Y' -> , Create_tmp_table_priv='Y'; This allows us to put a stop list together (currently containing only one entry for the public.example.com host) and deny access to connections originating from that server. Using the % wildcard this way in the Db column and in the Host column means that the access control system will always find a match in the host table for any internal example.com server, regard- less of the request. Since any privilege columns we leave out in the INSERT statement will default to 'N', we can rest assured that no unintended privileges have been granted. Remember, however, that the MySQL access control system will use privileges in the global mysql.user entry first in the privilege verification process. Therefore, if the account some_user@public.example.com had privileges set to 'Y' at the global level, that entry would override the host table entries. Managing User Accounts from the Command Line You can use SQL commands to add and remove user accounts, including several GRANT clauses to place restrictions on accounts. Here, we’ll look at those commands. In the next section, we’ll cover using the MySQL Administrator GUI tool to manage user accounts. Adding User Accounts As mentioned earlier, you can use the GRANT command to create new user accounts. Any time you issue a GRANT statement for a username and host combination that does not currently exist in the mysql.user table, a new user account is created. A row is inserted in the mysql.user table for the username and host specified in your GRANT statement. If the scope of the privi- leges granted in the statement is global, the user account’s global permissions will be set in this new row and no other tables will receive an entry. If the scope of privileges was below the global scope, a new entry will be inserted in the grant table corresponding to the privilege level. The IDENTIFIED BY clause of the GRANT statement allows you to specify a password for the user account, like so: GRANT SELECT ON ToyStore.* TO 'some_user'@'localhost' IDENTIFIED BY 'my_password'; CHAPTER 15 ■ USER ADMINISTRATION516 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 516 [...]... of the window This adds a new_user entry in the User Accounts list In the right pane, fill in the fields in the Login Information section, as shown in Figure 15 -8 Filling in the Additional Information area is strictly optional.3 Figure 15 -8 Filling in new user information When you are finished filling in the basic information, select the Schema Privileges tab In this tab, any privileges that you move... Connecting to the Server When you start up the MySQL Administrator program, you are greeted with the dialog box shown in Figure 15-3 ■ Note The figures in this section come from a computer running Fedora Core 3 Linux using the KDE desktop environment Although you may notice slight variations in the MySQL Administrator functionality, depending on the operating system you use, the interface runs in a very... using the MySQL Administrator GUI, walking through setting up a connection, and working in the User Administrator section Finally, we switched gears a bit and talked about the major difference between MySQL s user administration implementation and other database vendors: MySQL s lack of role-based account management We demonstrated some techniques for thinking in terms of role-based management and finished... display product information web_administrator shop customer, product SELECT web_administrator shop customer_order SELECT, INSERT, UPDATE Notes: The web_administrator is a user in the web application that is used specifically for creating and displaying customer orders DB Admins All All Notes: Database administrators have full access to the database All Maintaining a table such as the one shown in Table... access to services on the machine via a firewall or by disabling unnecessary programs and processes The public web site will obviously need to be accessed by anyone coming in from the Internet The order-processing and order-fulfillment pieces of the system are needed only by users within your office You might control access by using an internal network and binding an internal domain name or IP address to... data in your system In addition, a flaw in the protection of data can lead to long interruptions in business processes, and wasted employee time and company funds while data integrity issues are resolved In writing a chapter on database security, we don’t want to just provide a seemingly endless list of random thoughts on how to secure your system We don’t want to shake our finger at you, delivering... networking: If you use MySQL only on the local machine (you are physically at the machine, are using a secure connection to run a shell, or are using an application running on the same machine), turn off networking You can do this by setting skip-networking in your server startup configuration (see Chapter 14 for details on configuring MySQL) 1 You may use the anonymous account to make certain pieces... be protected and what parts of the system should be available to users This can be a time-consuming and challenging process Sometimes, just making sure you have all the right people involved in the conversation to define the security requirements can be a challenge Defining security policies warrants a thorough process of identifying all the stakeholders of the data and bringing them together to define... you assign through MySQL Administrator 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 527 CHAPTER 15 ■ USER ADMINISTRATION Figure 15-12 Turning on the global privilege editor Figure 15-13 The Global Privileges editor in MySQL Administrator 527 505x_Ch15_FINAL.qxd 5 28 6/27/05 3:35 PM Page 5 28 CHAPTER 15 ■ USER ADMINISTRATION Similarly, you can change table and column privileges by selecting the Table/Column... for granting access for specific parts of the database Operating System Overview of operating system procedures as they relate to the database Includes information about who has access to the server MySQL Installation Details about how MySQL is installed and configured Defines where data files are stored, what configuration options are specified, and whether networking is enabled Applications Information . the window. This adds a new_user entry in the User Accounts list. In the right pane, fill in the fields in the Login Information section, as shown in Figure 15 -8. Filling in the Additional Information. security risk. So, we run the following code: mysql& gt; INSERT INTO mysql. host SET Host='public.example.com', Db='%'; mysql& gt; INSERT INTO mysql. host SET Host='%.example.com',. privilege information and when it does not. CHAPTER 15 ■ USER ADMINISTRATION5 18 505x_Ch15_FINAL.qxd 6/27/05 3:35 PM Page 5 18 When In- Memory Tables Are Updated In all of the following situations, the in- memory