Jvn2k07.files.wordpress.com



MySQL Account Management Statements13.7.1.1.?CREATE USER StatementCreates new MySQL accounts.Syntax:CREATE USER user_specification [, user_specification] ...user_specification: user [IDENTIFIED BY [PASSWORD] 'password']Notations:To use it, you must have the global CREATE USER privilege or the INSERT privilege for the mysql database. For each account, CREATE USER creates a new row in the mysql.user table and assigns the account no privileges. An error occurs if the account already exists. Each account name uses the format described in Section?6.2.3, “Specifying Account Names”.Example: CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';If you specify only the user name part of the account name, a host name part of '%' is used. The user specification may indicate how the user should authenticate when connecting to the server: To enable the user to connect with no password (which is insecure), include no IDENTIFIED BY clause: CREATE USER 'jeffrey'@'localhost';To assign a password, use IDENTIFIED BY with the literal plaintext password value: CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';To avoid specifying the plaintext password if you know its hash value (the value that PASSWORD() would return for the password), specify the hash value preceded by the keyword PASSWORD: CREATE USER 'jeffrey'@'localhost'IDENTIFIED BY PASSWORD '*90E462C37378CED12064BB3388827D2BA3A9B689';For additional information about setting passwords, see Section?6.3.5, “Assigning Account Passwords”. Important: CREATE USER may be recorded in server logs or in a history file such as ~/.mysql_history, which means that cleartext passwords may be read by anyone having read access to that information. See Section?6.1.2, “Keeping Passwords Secure”. Important: Some releases of MySQL introduce changes to the structure of the grant tables to add new privileges or features. Whenever you update to a new version of MySQL, you should update your grant tables to make sure that they have the current structure so that you can take advantage of any new capabilities. See Section?4.4.9, “mysql_upgrade — Check Tables for MySQL Upgrade”. The CREATE USER statement was added in MySQL 5.0.2. 13.7.1.2.?DROP USER StatementRemoves one or more MySQL accounts.Syntax:DROP USER user [, user] ...Notations:To use it, you must have the global CREATE USER privilege or the DELETE privilege for the mysql database. Each account name uses the format described in Section?6.2.3, “Specifying Account Names”. Example: DROP USER 'jeffrey'@'localhost';If you specify only the user name part of the account name, a host name part of '%' is used. DROP USER as present in MySQL 5.0.0 removes only accounts that have no privileges. In MySQL 5.0.2, it was modified to remove account privileges as well. This means that the procedure for removing an account depends on your version of MySQL. As of MySQL 5.0.2, you can remove an account and its privileges as follows: DROP USER user;The statement removes privilege rows for the account from all grant tables. Before MySQL 5.0.2, DROP USER serves only to remove account rows from the user table for accounts that have no privileges. To remove a MySQL account completely (including all of its privileges), you should use the following procedure, performing these steps in the order shown: Use SHOW GRANTS to determine what privileges the account has. See Section?13.7.5.17, “SHOW GRANTS Syntax”. Use REVOKE to revoke the privileges displayed by SHOW GRANTS. This removes rows for the account from all the grant tables except the user table, and revokes any global privileges listed in the user table. See Section?13.7.1.3, “GRANT Syntax”. Delete the account by using DROP USER to remove the user table row. Important: DROP USER does not automatically close any open user sessions. Rather, in the event that a user with an open session is dropped, the statement does not take effect until that user's session is closed. Once the session is closed, the user is dropped, and that user's next attempt to log in will fail. This is by design. DROP USER does not automatically drop or invalidate databases or objects within them that the old user created. This includes stored programs or views for which the DEFINER attribute names the dropped user. Attempts to access such objects may produce an error if they execute in definer security context. (For information about security context, see Section?18.5, “Access Control for Stored Programs and Views”.) 13.7.1.3.?GRANT StatementThe GRANT statement grants privileges to MySQL user accounts. It also serves to specify other account characteristics such as use of secure connections and limits on access to server resources.Syntax:GRANT priv_type [(column_list)] [, priv_type [(column_list)]] ... ON [object_type] priv_level TO user_specification [, user_specification] ... [REQUIRE {NONE | ssl_option [[AND] ssl_option] ...}] [WITH with_option ...]object_type: TABLE | FUNCTION | PROCEDUREpriv_level: * | *.* | db_name.* | db_name.tbl_name | tbl_name | db_name.routine_nameuser_specification: user [IDENTIFIED BY [PASSWORD] 'password']ssl_option: SSL | X509 | CIPHER 'cipher' | ISSUER 'issuer' | SUBJECT 'subject'with_option: GRANT OPTION | MAX_QUERIES_PER_HOUR count | MAX_UPDATES_PER_HOUR count | MAX_CONNECTIONS_PER_HOUR count | MAX_USER_CONNECTIONS countNotations:To use GRANT, you must have the GRANT OPTION privilege, and you must have the privileges that you are granting. Normally, a database administrator first uses CREATE USER to create an account, then GRANT to define its privileges and characteristics. Examples: CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';GRANT ALL ON db1.* TO 'jeffrey'@'localhost';GRANT SELECT ON db2.invoice TO 'jeffrey'@'localhost';GRANT USAGE ON *.* TO 'jeffrey'@'localhost' WITH MAX_QUERIES_PER_HOUR 90;However, if an account named in a GRANT statement does not already exist, GRANT may create it under the conditions described later in the discussion of the NO_AUTO_CREATE_USER SQL mode. The REVOKE statement is related to GRANT and enables administrators to remove account privileges. See Section?13.7.1.5, “REVOKE Syntax”. When successfully executed from the mysql program, GRANT responds with Query OK, 0 rows affected. To determine what privileges result from the operation, use SHOW GRANTS. See Section?13.7.5.17, “SHOW GRANTS Syntax”. There are several aspects to the GRANT statement, described under the following topics in this section: Privileges Supported by MySQL Global Privileges Database Privileges Table Privileges Column Privileges Stored Routine Privileges Account Names and Passwords Other Account Characteristics MySQL and Standard SQL Versions of GRANT Important: Some releases of MySQL introduce changes to the structure of the grant tables to add new privileges or features. Whenever you update to a new version of MySQL, you should update your grant tables to make sure that they have the current structure so that you can take advantage of any new capabilities. See Section?4.4.9, “mysql_upgrade — Check Tables for MySQL Upgrade”. Privileges Supported by MySQL The following table summarizes the permissible priv_type privilege types that can be specified for the GRANT and REVOKE statements. For additional information about these privileges, see Section?6.2.1, “Privileges Provided by MySQL”. Table?13.1.?Permissible Privileges for GRANT and REVOKEPrivilegeMeaningALL [PRIVILEGES]Grant all privileges at specified access level except GRANT OPTIONALTEREnable use of ALTER TABLEALTER ROUTINEEnable stored routines to be altered or droppedCREATEEnable database and table creationCREATE ROUTINEEnable stored routine creationCREATE TEMPORARY TABLESEnable use of CREATE TEMPORARY TABLECREATE USEREnable use of CREATE USER, DROP USER, RENAME USER, and REVOKE ALL PRIVILEGESCREATE VIEWEnable views to be created or alteredDELETEEnable use of DELETEDROPEnable databases, tables, and views to be droppedEXECUTEEnable the user to execute stored routinesFILEEnable the user to cause the server to read or write filesGRANT OPTIONEnable privileges to be granted to or removed from other accountsINDEXEnable indexes to be created or droppedINSERTEnable use of INSERTLOCK TABLESEnable use of LOCK TABLES on tables for which you have the SELECT privilegePROCESSEnable the user to see all processes with SHOW PROCESSLISTREFERENCESNot implementedRELOADEnable use of FLUSH operationsREPLICATION CLIENTEnable the user to ask where master or slave servers areREPLICATION SLAVEEnable replication slaves to read binary log events from the masterSELECTEnable use of SELECTSHOW DATABASESEnable SHOW DATABASES to show all databasesSHOW VIEWEnable use of SHOW CREATE VIEWSHUTDOWNEnable use of mysqladmin shutdownSUPEREnable use of other administrative operations such as CHANGE MASTER TO, KILL, PURGE BINARY LOGS, SET GLOBAL, and mysqladmin debug commandUPDATEEnable use of UPDATEUSAGESynonym for “no privileges”The EXECUTE privilege is not operational until MySQL 5.0.3. CREATE VIEW and SHOW VIEW were added in MySQL 5.0.1. CREATE USER, CREATE ROUTINE, and ALTER ROUTINE were added in MySQL 5.0.3. In GRANT statements, the ALL [PRIVILEGES] privilege is named by itself and cannot be specified along with other privileges. It stands for all privileges available for the level at which privileges are to be granted except for the GRANT OPTION privilege. USAGE can be specified to create a user that has no privileges, or to specify the REQUIRE or WITH clauses for an account without changing its existing privileges. MySQL account information is stored in the tables of the mysql database. This database and the access control system are discussed extensively in Section?6.2, “The MySQL Access Privilege System”, which you should consult for additional details. If the grant tables hold privilege rows that contain mixed-case database or table names and the lower_case_table_names system variable is set to a nonzero value, REVOKE cannot be used to revoke these privileges. It will be necessary to manipulate the grant tables directly. (GRANT will not create such rows when lower_case_table_names is set, but such rows might have been created prior to setting that variable.) Privileges can be granted at several levels, depending on the syntax used for the ON clause. For REVOKE, the same ON syntax specifies which privileges to take away. The examples shown here include no IDENTIFIED BY 'password' clause for brevity, but you should include one if the account does not already exist, to avoid creating an insecure account that has no password. Global Privileges Global privileges are administrative or apply to all databases on a given server. To assign global privileges, use ON *.* Syntax: GRANT ALL ON *.* TO 'someuser'@'somehost';GRANT SELECT, INSERT ON *.* TO 'someuser'@'somehost';Before MySQL 5.0.23, privileges also are assigned at the global level if you use ON * syntax and you have not selected a default database. As of 5.0.23, ON * requires a default database and produces an error if there is none. The CREATE USER, FILE, PROCESS, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHOW DATABASES, SHUTDOWN, and SUPER privileges are administrative and can only be granted globally. Other privileges can be granted globally or at more specific levels. MySQL stores global privileges in the mysql.user table. Database Privileges Database privileges apply to all objects in a given database. To assign database-level privileges, use ON db_name.* syntax: GRANT ALL ON mydb.* TO 'someuser'@'somehost';GRANT SELECT, INSERT ON mydb.* TO 'someuser'@'somehost';If you use ON * syntax (rather than ON *.*) and you have selected a default database, privileges are assigned at the database level for the default database. An error occurs if there is no default database. The CREATE, DROP, GRANT OPTION, and LOCK TABLES privileges can be specified at the database level. Table or routine privileges also can be specified at the database level, in which case they apply to all tables or routines in the database. MySQL stores database privileges in the mysql.db table. Table Privileges Table privileges apply to all columns in a given table. To assign table-level privileges, use ON db_name.tbl_name syntax: GRANT ALL ON mydb.mytbl TO 'someuser'@'somehost';GRANT SELECT, INSERT ON mydb.mytbl TO 'someuser'@'somehost';If you specify tbl_name rather than db_name.tbl_name, the statement applies to tbl_name in the default database. An error occurs if there is no default database. The permissible priv_type values at the table level are ALTER, CREATE VIEW, CREATE, DELETE, DROP, GRANT OPTION, INDEX, INSERT, SELECT, SHOW VIEW, and UPDATE. MySQL stores table privileges in the mysql.tables_priv table. Column Privileges Column privileges apply to single columns in a given table. Each privilege to be granted at the column level must be followed by the column or columns, enclosed within parentheses. GRANT SELECT (col1), INSERT (col1,col2) ON mydb.mytbl TO 'someuser'@'somehost';The permissible priv_type values for a column (that is, when you use a column_list clause) are INSERT, SELECT, and UPDATE. MySQL stores column privileges in the mysql.columns_priv table. Stored Routine Privileges The ALTER ROUTINE, CREATE ROUTINE, EXECUTE, and GRANT OPTION privileges apply to stored routines (procedures and functions). They can be granted at the global and database levels. Except for CREATE ROUTINE, these privileges can be granted at the routine level for individual routines.GRANT CREATE ROUTINE ON mydb.* TO 'someuser'@'somehost';GRANT EXECUTE ON PROCEDURE mydb.myproc TO 'someuser'@'somehost';The permissible priv_type values at the routine level are ALTER ROUTINE, EXECUTE, and GRANT OPTION. CREATE ROUTINE is not a routine-level privilege because you must have this privilege to create a routine in the first place. MySQL stores routine-level privileges in the mysql.procs_priv table. For the global, database, table, and routine levels, GRANT ALL assigns only the privileges that exist at the level you are granting. For example, GRANT ALL ON db_name.* is a database-level statement, so it does not grant any global-only privileges such as FILE. The object_type clause was added in MySQL 5.0.6. If present, it should be specified as TABLE, FUNCTION, or PROCEDURE when the following object is a table, a stored function, or a stored procedure. The privileges for a database, table, column, or routine are formed additively as the logical OR of the privileges at each of the privilege levels. For example, if a user has a global SELECT privilege, the privilege cannot be denied by an absence of the privilege at the database, table, or column level. Details of the privilege-checking procedure are presented in Section?6.2.5, “Access Control, Stage 2: Request Verification”. MySQL enables you to grant privileges on databases or tables that do not exist. For tables, the privileges to be granted must include the CREATE privilege. This behavior is by design, and is intended to enable the database administrator to prepare user accounts and privileges for databases or tables that are to be created at a later time. Important: MySQL does not automatically revoke any privileges when you drop a database or table. However, if you drop a routine, any routine-level privileges granted for that routine are revoked. Account Names and Passwords The user value indicates the MySQL account to which the GRANT statement applies. To accommodate granting rights to users from arbitrary hosts, MySQL supports specifying the user value in the form user_name@host_name. If a user_name or host_name value is legal as an unquoted identifier, you need not quote it. However, quotation marks are necessary to specify a user_name string containing special characters (such as “-”), or a host_name string containing special characters or wildcard characters (such as “%”); for example, 'test-user'@'%.com'. Quote the user name and host name separately. You can specify wildcards in the host name. For example, user_name@'%.' applies to user_name for any host in the domain, and user_name@'192.168.1.%' applies to user_name for any host in the 192.168.1 class C subnet. The simple form user_name is a synonym for user_name@'%'. MySQL does not support wildcards in user names. To refer to an anonymous user, specify an account with an empty user name with the GRANT statement: GRANT ALL ON test.* TO ''@'localhost' ...In this case, any user who connects from the local host with the correct password for the anonymous user will be permitted access, with the privileges associated with the anonymous-user account. For additional information about user name and host name values in account names, see Section?6.2.3, “Specifying Account Names”. To specify quoted values, quote database, table, column, and routine names as identifiers. Quote user names and host names as identifiers or as strings. Quote passwords as strings. For string-quoting and identifier-quoting guidelines, see Section?9.1.1, “String Literals”, and Section?9.2, “Schema Object Names”. The “_” and “%” wildcards are permitted when specifying database names in GRANT statements that grant privileges at the global or database levels. This means, for example, that if you want to use a “_” character as part of a database name, you should specify it as “\_” in the GRANT statement, to prevent the user from being able to access additional databases matching the wildcard pattern; for example, GRANT ... ON `foo\_bar`.* TO .... Warning: If you permit anonymous users to connect to the MySQL server, you should also grant privileges to all local users as user_name@localhost. Otherwise, the anonymous user account for localhost in the mysql.user table (created during MySQL installation) is used when named users try to log in to the MySQL server from the local machine. For details, see Section?6.2.4, “Access Control, Stage 1: Connection Verification”. To determine whether the preceding warning applies to you, execute the following query, which lists any anonymous users: SELECT Host, User FROM mysql.user WHERE User='';To avoid the problem just described, delete the local anonymous user account using this statement: DROP USER ''@'localhost';GRANT supports host names up to 60 characters long. Database, table, column, and routine names can be up to 64 characters. User names can be up to 16 characters. Warning: The permissible length for user names cannot be changed by altering the mysql.user table. Attempting to do so results in unpredictable behavior which may even make it impossible for users to log in to the MySQL server. You should never alter any of the tables in the mysql database in any manner whatsoever except by means of the procedure described in Section?4.4.9, “mysql_upgrade — Check Tables for MySQL Upgrade”. The user specification may indicate how the user should authenticate when connecting to the server, through inclusion of an IDENTIFIED BY clause. The syntax is the same as for the CREATE USER statement. See Section?13.7.1.1, “CREATE USER Syntax”. When the IDENTIFIED BY clause is present and you have global grant privileges, the password becomes the new password for the account, even if the account exists and already has a password. With no IDENTIFIED BY clause, the account password remains unchanged. If the NO_AUTO_CREATE_USER SQL mode is not enabled and the account named in a GRANT statement does not exist in the mysql.user table, GRANT creates it. If you specify no IDENTIFIED BY clause or provide an empty password, the user has no password. This is very insecure. If NO_AUTO_CREATE_USER is enabled and the account does not exist, GRANT fails and does not create the account unless the IDENTIFIED BY clause is given to provide a nonempty password. Important : GRANT may be recorded in server logs or in a history file such as ~/.mysql_history, which means that cleartext passwords may be read by anyone having read access to that information. See Section?6.1.2, “Keeping Passwords Secure”. Other Account Characteristics The WITH clause is used for several purposes: To enable a user to grant privileges to other users To specify resource limits for a user To specify whether and how a user must use secure connections to the server The WITH GRANT OPTION clause gives the user the ability to give to other users any privileges the user has at the specified privilege level. You should be careful to whom you give the GRANT OPTION privilege because two users with different privileges may be able to combine privileges! You cannot grant another user a privilege which you yourself do not have; the GRANT OPTION privilege enables you to assign only those privileges which you yourself possess. Be aware that when you grant a user the GRANT OPTION privilege at a particular privilege level, any privileges the user possesses (or may be given in the future) at that level can also be granted by that user to other users. Suppose that you grant a user the INSERT privilege on a database. If you then grant the SELECT privilege on the database and specify WITH GRANT OPTION, that user can give to other users not only the SELECT privilege, but also INSERT. If you then grant the UPDATE privilege to the user on the database, the user can grant INSERT, SELECT, and UPDATE. For a nonadministrative user, you should not grant the ALTER privilege globally or for the mysql database. If you do that, the user can try to subvert the privilege system by renaming tables! For additional information about security risks associated with particular privileges, see Section?6.2.1, “Privileges Provided by MySQL”. Several WITH clause options specify limits on use of server resources by an account: The MAX_QUERIES_PER_HOUR count, MAX_UPDATES_PER_HOUR count, and MAX_CONNECTIONS_PER_HOUR count limits restrict the number of queries, updates, and connections to the server permitted to this account during any given one-hour period. (Queries for which results are served from the query cache do not count against the MAX_QUERIES_PER_HOUR limit.) If count is 0 (the default), this means that there is no limitation for the account. The MAX_USER_CONNECTIONS count limit, implemented in MySQL 5.0.3, restricts the maximum number of simultaneous connections to the server by the account. A nonzero count specifies the limit for the account explicitly. If count is 0 (the default), the server determines the number of simultaneous connections for the account from the global value of the max_user_connections system variable. If max_user_connections is also zero, there is no limit for the account. To specify resource limits for an existing user without affecting existing privileges, use GRANT USAGE at the global level (ON *.*) and name the limits to be changed. For example: GRANT USAGE ON *.* TO ...WITH MAX_QUERIES_PER_HOUR 500 MAX_UPDATES_PER_HOUR 100;Limits not specified retain their current values. For more information on restricting access to server resources, see Section?6.3.4, “Setting Account Resource Limits”. MySQL can check X509 certificate attributes in addition to the usual authentication that is based on the user name and password. To specify SSL-related options for a MySQL account, use the REQUIRE clause of the GRANT statement. (For background information on the use of SSL with MySQL, see Section?6.3.6, “Using SSL for Secure Connections”.) There are a number of different possibilities for limiting connection types for a given account: REQUIRE NONE indicates that the account has no SSL or X509 requirements. This is the default if no SSL-related REQUIRE options are specified. Unencrypted connections are permitted if the user name and password are valid. However, encrypted connections can also be used, at the client's option, if the client has the proper certificate and key files. That is, the client need not specify any SSL command options, in which case the connection will be unencrypted. To use an encrypted connection, the client must specify either the --ssl-ca option, or all three of the --ssl-ca, --ssl-key, and --ssl-cert options. The REQUIRE SSL option tells the server to permit only SSL-encrypted connections for the account. GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE SSL;To connect, the client must specify the --ssl-ca option to authenticate the server certificate, and may additionally specify the --ssl-key and --ssl-cert options. If neither --ssl-ca option nor --ssl-capath option is specified, the client does not authenticate the server certificate. REQUIRE X509 means that the client must have a valid certificate but that the exact certificate, issuer, and subject do not matter. The only requirement is that it should be possible to verify its signature with one of the CA certificates. GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE X509;To connect, the client must specify the --ssl-ca, --ssl-key, and --ssl-cert options. This is also true for ISSUER and SUBJECT because those REQUIRE options imply X509. REQUIRE ISSUER 'issuer' places the restriction on connection attempts that the client must present a valid X509 certificate issued by CA 'issuer'. If the client presents a certificate that is valid but has a different issuer, the server rejects the connection. Use of X509 certificates always implies encryption, so the SSL option is unnecessary in this case. GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret'REQUIRE ISSUER '/C=FI/ST=Some-State/L=Helsinki/O=MySQL Finland AB/CN=Tonu Samuel/emailAddress=tonu@';The 'issuer' value should be entered as a single string. Note: If MySQL is linked against a version of OpenSSL older than 0.9.6h, use Email rather than emailAddress in the 'issuer' value. REQUIRE SUBJECT 'subject' places the restriction on connection attempts that the client must present a valid X509 certificate containing the subject subject. If the client presents a certificate that is valid but has a different subject, the server rejects the connection. GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret'REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/O=MySQL demo client certificate/CN=Tonu Samuel/emailAddress=tonu@';The 'subject' value should be entered as a single string. MySQL does a simple string comparison of this value to the value in the certificate, so lettercase and component ordering must be given exactly as present in the certificate. Note: Regarding emailAddress, see the note in the description of REQUIRE ISSUER. REQUIRE CIPHER 'cipher' is needed to ensure that ciphers and key lengths of sufficient strength are used. SSL itself can be weak if old algorithms using short encryption keys are used. Using this option, you can ask that a specific cipher method is used for a connection. GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE CIPHER 'EDH-RSA-DES-CBC3-SHA';The SUBJECT, ISSUER, and CIPHER options can be combined in the REQUIRE clause like this: GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/O=MySQL demo client certificate/ CN=Tonu Samuel/emailAddress=tonu@' AND ISSUER '/C=FI/ST=Some-State/L=Helsinki/ O=MySQL Finland AB/CN=Tonu Samuel/emailAddress=tonu@' AND CIPHER 'EDH-RSA-DES-CBC3-SHA';The order of the options does not matter, but no option can be specified twice. The AND keyword is optional between REQUIRE options. If you are using table, column, or routine privileges for even one user, the server examines table, column, and routine privileges for all users and this slows down MySQL a bit. Similarly, if you limit the number of queries, updates, or connections for any users, the server must monitor these values. MySQL and Standard SQL Versions of GRANT The biggest differences between the MySQL and standard SQL versions of GRANT are: MySQL associates privileges with the combination of a host name and user name and not with only a user name. Standard SQL does not have global or database-level privileges, nor does it support all the privilege types that MySQL supports. MySQL does not support the standard SQL UNDER privilege, and does not support the TRIGGER privilege until MySQL 5.1.6. Standard SQL privileges are structured in a hierarchical manner. If you remove a user, all privileges the user has been granted are revoked. This is also true in MySQL 5.0.2 and up if you use DROP USER. Before 5.0.2, the granted privileges are not automatically revoked; you must revoke them yourself. See Section?13.7.1.2, “DROP USER Syntax”. In standard SQL, when you drop a table, all privileges for the table are revoked. In standard SQL, when you revoke a privilege, all privileges that were granted based on that privilege are also revoked. In MySQL, privileges can be dropped only with explicit DROP USER or REVOKE statements or by manipulating the MySQL grant tables directly. In MySQL, it is possible to have the INSERT privilege for only some of the columns in a table. In this case, you can still execute INSERT statements on the table, provided that you insert values only for those columns for which you have the INSERT privilege. The omitted columns are set to their implicit default values if strict SQL mode is not enabled. In strict mode, the statement is rejected if any of the omitted columns have no default value. (Standard SQL requires you to have the INSERT privilege on all columns.) Section?5.1.7, “Server SQL Modes”, discusses strict mode. Section?11.1.7, “Data Type Default Values”, discusses implicit default values. 13.7.1.4. RENAME USER StatementRenames existing MySQL accounts.Syntax: RENAME USER old_user TO new_user [, old_user TO new_user] ...Notations:To use it, you must have the global CREATE USER privilege or the UPDATE privilege for the mysql database. An error occurs if any old account does not exist or any new account exists. Each account name uses the format described in Section?6.2.3, “Specifying Account Names”. If you specify only the user name part of the account name, a host name part of '%' is used. RENAME USER causes the privileges held by the old user to be those held by the new user. However, RENAME USER does not automatically drop or invalidate databases or objects within them that the old user created. This includes stored programs or views for which the DEFINER attribute names the old user. Attempts to access such objects may produce an error if they execute in definer security context. (For information about security context, see Section?18.5, “Access Control for Stored Programs and Views”.) The privilege changes take effect as indicated in Section?6.2.6, “When Privilege Changes Take Effect”. The RENAME USER statement was added in MySQL 5.0.2.Example: RENAME USER 'jeffrey'@'localhost' TO 'jeff'@'127.0.0.1';13.7.1.5. REVOKE StatementEnables system administrators to revoke privileges from MySQL accounts.Syntax: REVOKE priv_type [(column_list)] [, priv_type [(column_list)]] ... ON [object_type] priv_level FROM user [, user] ...REVOKE ALL PRIVILEGES, GRANT OPTION FROM user [, user] ...Notations: Each account name uses the format described in Section?6.2.3, “Specifying Account Names”. If you specify only the user name part of the account name, a host name part of '%' is used. For details on the levels at which privileges exist, the permissible priv_type and priv_level values, and the syntax for specifying users and passwords, see Section?13.7.1.3, “GRANT Syntax” To use the first REVOKE syntax, you must have the GRANT OPTION privilege, and you must have the privileges that you are revoking. To revoke all privileges, use the second syntax, which drops all global, database, table, column, and routine privileges for the named user or users: REVOKE ALL PRIVILEGES, GRANT OPTION FROM user [, user] ...To use this REVOKE syntax, you must have the global CREATE USER privilege or the UPDATE privilege for the mysql database. REVOKE removes privileges, but does not drop mysql.user table entries. To remove a user account entirely, use DROP USER (see Section?13.7.1.2, “DROP USER Syntax”) or DELETE. If the grant tables hold privilege rows that contain mixed-case database or table names and the lower_case_table_names system variable is set to a nonzero value, REVOKE cannot be used to revoke these privileges. It will be necessary to manipulate the grant tables directly. (GRANT will not create such rows when lower_case_table_names is set, but such rows might have been created prior to setting the variable.) When successfully executed from the mysql program, REVOKE responds with Query OK, 0 rows affected. To determine what privileges result from the operation, use SHOW GRANTS. See Section?13.7.5.17, “SHOW GRANTS Syntax”. Example: REVOKE INSERT ON *.* FROM 'jeffrey'@'localhost';13.7.1.6. SET PASSWORD StatementSyntax:SET PASSWORD [FOR user] = { PASSWORD('cleartext password') | OLD_PASSWORD('cleartext password') | 'encrypted password' }The SET PASSWORD statement assigns a password to an existing MySQL user account. In MySQL 5.0, enabling the read_only system variable does not prevent use of SET PASSWORD. If the password is specified using the PASSWORD() or OLD_PASSWORD() function, the cleartext (unencrypted) password should be given as the argument to the function, which hashes the password and returns the encrypted password string. If the password is specified without using either function, it should be the already encrypted password value as a literal string. In all cases, the encrypted password string must be in the format required by the authentication method used for the account. With no FOR user clause, this statement sets the password for the current user. (To see which account the server authenticat ed you as, invoke the CURRENT_USER() function.) Any client who successfully connects to the server using a nonanonymous account can change the password for that account. With a FOR user clause, this statement sets the password for the named user. You must have the UPDATE privilege for the mysql database to do this. The user account name uses the format described in Section?6.2.3, “Specifying Account Names”. The user value should be given as 'user_name'@'host_name', where 'user_name' and 'host_name' are exactly as listed in the User and Host columns of the mysql.user table row. (If you specify only a user name, a host name of '%' is used.) For example, to set the password for an account with User and Host column values of 'bob' and '%.', write the statement like this: SET PASSWORD FOR 'bob'@'%.' = PASSWORD('cleartext password');That is equivalent to the following statements: UPDATE mysql.user SET Password=PASSWORD('cleartext password') WHERE User='bob' AND Host='%.';FLUSH PRIVILEGES;Another way to set the password is to use GRANT: GRANT USAGE ON *.* TO 'bob'@'%.' IDENTIFIED BY 'cleartext password';The old_passwords system variable value determines the hashing method used by PASSWORD(). If you specify the password using that function and SET PASSWORD rejects the password as not being in the correct format, it may be necessary to set old_passwords to change the hashing method. For descriptions of the permitted values, see Section?5.1.4, “Server System Variables”. For more information about setting passwords, see Section?6.3.5, “Assigning Account Passwords” Important: SET PASSWORD may be recorded in server logs or in a history file such as ~/.mysql_history, which means that cleartext passwords may be read by anyone having read access to that information. See Section?6.1.2, “Keeping Passwords Secure”. Caution: If you are connecting to a MySQL 4.1 or later server using a pre-4.1 client program, do not change your password without first reading Section?6.1.2.4, “Password Hashing in MySQL”. The default password hashing format changed in MySQL 4.1, and if you change your password, it might be stored using a hashing format that pre-4.1 clients cannot generate, thus preventing you from connecting to the server afterward. If you are using MySQL Replication, be aware that, currently, a password used by a replication slave as part of a CHANGE MASTER TO statement is effectively limited to 32 characters in length; the password can be longer, but any excess characters are truncated. This is not due to any limit imposed by the MySQL Server generally, but rather is an issue specific to MySQL Replication. (For more information, see Bug #43439.) Copyright ? 1997, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download