| List: | Commits | « Previous MessageNext Message » | |
| From: | paul.dubois | Date: | January 14 2009 10:59pm |
| Subject: | svn commit - mysqldoc@docsrva: r13194 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | ||
| View as plain text | |||
Author: paul Date: 2009-01-14 22:59:17 +0100 (Wed, 14 Jan 2009) New Revision: 13194 Log: r37360@frost: paul | 2009-01-14 16:00:19 -0500 Revisions to access-control discussion Modified: trunk/refman-4.1/dba-privilege-system.xml trunk/refman-5.0/dba-privilege-system.xml trunk/refman-5.1/dba-privilege-system.xml trunk/refman-6.0/dba-privilege-system.xml Property changes on: trunk ___________________________________________________________________ Name: svk:merge - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:41130 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:37359 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:35643 + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:41130 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:37360 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:35643 Modified: trunk/refman-4.1/dba-privilege-system.xml =================================================================== --- trunk/refman-4.1/dba-privilege-system.xml 2009-01-14 21:59:10 UTC (rev 13193) +++ trunk/refman-4.1/dba-privilege-system.xml 2009-01-14 21:59:17 UTC (rev 13194) Changed blocks: 4, Lines Added: 41, Lines Deleted: 42; 5356 bytes @@ -2130,9 +2130,8 @@ <literal role="stmt">REVOKE</literal> statements, so it is unused in most MySQL installations. If you modify it directly, you can use it for some specialized purposes, such as to maintain a list - of secure servers. For example, at TcX, the - <literal>host</literal> table contains a list of all machines on - the local network. These are granted all privileges. + of secure servers on the local network that are granted all + privileges. </para> <para> @@ -2191,10 +2190,39 @@ </para> <para> - When the server reloads the grant tables, privileges for existing - client connections are affected as follows: + If you modify the grant tables indirectly using account-management + statements such as <literal role="stmt">GRANT</literal>, + <literal role="stmt">REVOKE</literal>, or <literal role="stmt">SET + PASSWORD</literal>, the server notices these changes and loads the + grant tables into memory again immediately. </para> + <para> + If you modify the grant tables directly using statements such as + <literal role="stmt">INSERT</literal>, + <literal role="stmt">UPDATE</literal>, or + <literal role="stmt">DELETE</literal>, your changes have no effect + on privilege checking until you either restart the server or tell + it to reload the tables. If you change the grant tables directly + but forget to reload them, your changes have <emphasis>no + effect</emphasis> until you restart the server. This may leave you + wondering why your changes do not seem to make any difference! + </para> + + <para> + To tell the sever to reload the grant tables, perform a + flush-privileges operation. This can be done by issuing a + <literal role="stmt" condition="flush">FLUSH PRIVILEGES</literal> + statement or by executing a <command>mysqladmin + flush-privileges</command> or <command>mysqladmin reload</command> + command. + </para> + + <para> + When the server reloads the grant tables, privileges for each + existing client connection are affected as follows: + </para> + <itemizedlist> <listitem> @@ -2206,60 +2234,31 @@ <listitem> <para> - Database privilege changes take effect at the next - <literal>USE <replaceable>db_name</replaceable></literal> - statement. + Database privilege changes take effect the next time the + client executes a <literal>USE + <replaceable>db_name</replaceable></literal> statement. </para> <note> <para> Client applications may cache the database name; thus, this effect may not be visible to them without actually changing - to a different database or executing a - <literal role="stmt" condition="flush">FLUSH - PRIVILEGES</literal> statement. + to a different database or flushing the privileges. </para> </note> </listitem> <listitem> <para> - Changes to global privileges and passwords take effect the - next time the client connects. + Global privileges and passwords are unaffected for a connected + client. These changes take effect only for subsequent + connections. </para> </listitem> </itemizedlist> <para> - If you modify the grant tables indirectly using statements such as - <literal role="stmt">GRANT</literal>, - <literal role="stmt">REVOKE</literal>, or <literal role="stmt">SET - PASSWORD</literal>, the server notices these changes and loads the - grant tables into memory again immediately. - </para> - - <para> - If you modify the grant tables directly using statements such as - <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal>, or - <literal role="stmt">DELETE</literal>, your changes have no effect - on privilege checking until you either restart the server or tell - it to reload the tables. To reload the grant tables manually, - issue a <literal role="stmt" condition="flush">FLUSH - PRIVILEGES</literal> statement or execute a <command>mysqladmin - flush-privileges</command> or <command>mysqladmin reload</command> - command. - </para> - - <para> - If you change the grant tables directly but forget to reload them, - your changes have <emphasis>no effect</emphasis> until you restart - the server. This may leave you wondering why your changes do not - seem to make any difference! - </para> - - <para> If the server is started with the <option>--skip-grant-tables</option> option, it does not read the grant tables or implement any access control. Anyone can connect @@ -2271,7 +2270,7 @@ <section id="access-denied"> - <title>Causes of <literal>Access denied</literal> Errors</title> + <title>Causes of Access-Denied Errors</title> <para> If you encounter problems when you try to connect to the MySQL Modified: trunk/refman-5.0/dba-privilege-system.xml =================================================================== --- trunk/refman-5.0/dba-privilege-system.xml 2009-01-14 21:59:10 UTC (rev 13193) +++ trunk/refman-5.0/dba-privilege-system.xml 2009-01-14 21:59:17 UTC (rev 13194) Changed blocks: 5, Lines Added: 42, Lines Deleted: 43; 5886 bytes @@ -2241,7 +2241,7 @@ checks the user's table and column privileges in the <literal>tables_priv</literal> and <literal>columns_priv</literal> tables, adds those to the user's privileges, and allows or denies - access based on the result. For stored routine operations, the + access based on the result. For stored-routine operations, the server uses the <literal>procs_priv</literal> table rather than <literal>tables_priv</literal> and <literal>columns_priv</literal>. @@ -2293,9 +2293,8 @@ <literal role="stmt">REVOKE</literal> statements, so it is unused in most MySQL installations. If you modify it directly, you can use it for some specialized purposes, such as to maintain a list - of secure servers. For example, at TcX, the - <literal>host</literal> table contains a list of all machines on - the local network. These are granted all privileges. + of secure servers on the local network that are granted all + privileges. </para> <para> @@ -2354,10 +2353,39 @@ </para> <para> - When the server reloads the grant tables, privileges for existing - client connections are affected as follows: + If you modify the grant tables indirectly using account-management + statements such as <literal role="stmt">GRANT</literal>, + <literal role="stmt">REVOKE</literal>, or <literal role="stmt">SET + PASSWORD</literal>, the server notices these changes and loads the + grant tables into memory again immediately. </para> + <para> + If you modify the grant tables directly using statements such as + <literal role="stmt">INSERT</literal>, + <literal role="stmt">UPDATE</literal>, or + <literal role="stmt">DELETE</literal>, your changes have no effect + on privilege checking until you either restart the server or tell + it to reload the tables. If you change the grant tables directly + but forget to reload them, your changes have <emphasis>no + effect</emphasis> until you restart the server. This may leave you + wondering why your changes do not seem to make any difference! + </para> + + <para> + To tell the sever to reload the grant tables, perform a + flush-privileges operation. This can be done by issuing a + <literal role="stmt" condition="flush">FLUSH PRIVILEGES</literal> + statement or by executing a <command>mysqladmin + flush-privileges</command> or <command>mysqladmin reload</command> + command. + </para> + + <para> + When the server reloads the grant tables, privileges for each + existing client connection are affected as follows: + </para> + <itemizedlist> <listitem> @@ -2369,60 +2397,31 @@ <listitem> <para> - Database privilege changes take effect at the next - <literal>USE <replaceable>db_name</replaceable></literal> - statement. + Database privilege changes take effect the next time the + client executes a <literal>USE + <replaceable>db_name</replaceable></literal> statement. </para> <note> <para> Client applications may cache the database name; thus, this effect may not be visible to them without actually changing - to a different database or executing a - <literal role="stmt" condition="flush">FLUSH - PRIVILEGES</literal> statement. + to a different database or flushing the privileges. </para> </note> </listitem> <listitem> <para> - Changes to global privileges and passwords take effect the - next time the client connects. + Global privileges and passwords are unaffected for a connected + client. These changes take effect only for subsequent + connections. </para> </listitem> </itemizedlist> <para> - If you modify the grant tables indirectly using statements such as - <literal role="stmt">GRANT</literal>, - <literal role="stmt">REVOKE</literal>, or <literal role="stmt">SET - PASSWORD</literal>, the server notices these changes and loads the - grant tables into memory again immediately. - </para> - - <para> - If you modify the grant tables directly using statements such as - <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal>, or - <literal role="stmt">DELETE</literal>, your changes have no effect - on privilege checking until you either restart the server or tell - it to reload the tables. To reload the grant tables manually, - issue a <literal role="stmt" condition="flush">FLUSH - PRIVILEGES</literal> statement or execute a <command>mysqladmin - flush-privileges</command> or <command>mysqladmin reload</command> - command. - </para> - - <para> - If you change the grant tables directly but forget to reload them, - your changes have <emphasis>no effect</emphasis> until you restart - the server. This may leave you wondering why your changes do not - seem to make any difference! - </para> - - <para> If the server is started with the <option>--skip-grant-tables</option> option, it does not read the grant tables or implement any access control. Anyone can connect @@ -2434,7 +2433,7 @@ <section id="access-denied"> - <title>Causes of <literal>Access denied</literal> Errors</title> + <title>Causes of Access-Denied Errors</title> <remark role="todo"> some of these items apply only to old systems and are now more of Modified: trunk/refman-5.1/dba-privilege-system.xml =================================================================== --- trunk/refman-5.1/dba-privilege-system.xml 2009-01-14 21:59:10 UTC (rev 13193) +++ trunk/refman-5.1/dba-privilege-system.xml 2009-01-14 21:59:17 UTC (rev 13194) Changed blocks: 5, Lines Added: 42, Lines Deleted: 43; 5886 bytes @@ -2245,7 +2245,7 @@ checks the user's table and column privileges in the <literal>tables_priv</literal> and <literal>columns_priv</literal> tables, adds those to the user's privileges, and allows or denies - access based on the result. For stored routine operations, the + access based on the result. For stored-routine operations, the server uses the <literal>procs_priv</literal> table rather than <literal>tables_priv</literal> and <literal>columns_priv</literal>. @@ -2297,9 +2297,8 @@ <literal role="stmt">REVOKE</literal> statements, so it is unused in most MySQL installations. If you modify it directly, you can use it for some specialized purposes, such as to maintain a list - of secure servers. For example, at TcX, the - <literal>host</literal> table contains a list of all machines on - the local network. These are granted all privileges. + of secure servers on the local network that are granted all + privileges. </para> <para> @@ -2358,10 +2357,39 @@ </para> <para> - When the server reloads the grant tables, privileges for existing - client connections are affected as follows: + If you modify the grant tables indirectly using account-management + statements such as <literal role="stmt">GRANT</literal>, + <literal role="stmt">REVOKE</literal>, or <literal role="stmt">SET + PASSWORD</literal>, the server notices these changes and loads the + grant tables into memory again immediately. </para> + <para> + If you modify the grant tables directly using statements such as + <literal role="stmt">INSERT</literal>, + <literal role="stmt">UPDATE</literal>, or + <literal role="stmt">DELETE</literal>, your changes have no effect + on privilege checking until you either restart the server or tell + it to reload the tables. If you change the grant tables directly + but forget to reload them, your changes have <emphasis>no + effect</emphasis> until you restart the server. This may leave you + wondering why your changes do not seem to make any difference! + </para> + + <para> + To tell the sever to reload the grant tables, perform a + flush-privileges operation. This can be done by issuing a + <literal role="stmt" condition="flush">FLUSH PRIVILEGES</literal> + statement or by executing a <command>mysqladmin + flush-privileges</command> or <command>mysqladmin reload</command> + command. + </para> + + <para> + When the server reloads the grant tables, privileges for each + existing client connection are affected as follows: + </para> + <itemizedlist> <listitem> @@ -2373,60 +2401,31 @@ <listitem> <para> - Database privilege changes take effect at the next - <literal>USE <replaceable>db_name</replaceable></literal> - statement. + Database privilege changes take effect the next time the + client executes a <literal>USE + <replaceable>db_name</replaceable></literal> statement. </para> <note> <para> Client applications may cache the database name; thus, this effect may not be visible to them without actually changing - to a different database or executing a - <literal role="stmt" condition="flush">FLUSH - PRIVILEGES</literal> statement. + to a different database or flushing the privileges. </para> </note> </listitem> <listitem> <para> - Changes to global privileges and passwords take effect the - next time the client connects. + Global privileges and passwords are unaffected for a connected + client. These changes take effect only for subsequent + connections. </para> </listitem> </itemizedlist> <para> - If you modify the grant tables indirectly using statements such as - <literal role="stmt">GRANT</literal>, - <literal role="stmt">REVOKE</literal>, or <literal role="stmt">SET - PASSWORD</literal>, the server notices these changes and loads the - grant tables into memory again immediately. - </para> - - <para> - If you modify the grant tables directly using statements such as - <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal>, or - <literal role="stmt">DELETE</literal>, your changes have no effect - on privilege checking until you either restart the server or tell - it to reload the tables. To reload the grant tables manually, - issue a <literal role="stmt" condition="flush">FLUSH - PRIVILEGES</literal> statement or execute a <command>mysqladmin - flush-privileges</command> or <command>mysqladmin reload</command> - command. - </para> - - <para> - If you change the grant tables directly but forget to reload them, - your changes have <emphasis>no effect</emphasis> until you restart - the server. This may leave you wondering why your changes do not - seem to make any difference! - </para> - - <para> If the server is started with the <option>--skip-grant-tables</option> option, it does not read the grant tables or implement any access control. Anyone can connect @@ -2438,7 +2437,7 @@ <section id="access-denied"> - <title>Causes of <literal>Access denied</literal> Errors</title> + <title>Causes of Access-Denied Errors</title> <remark role="todo"> some of these items apply only to old systems and are now more of Modified: trunk/refman-6.0/dba-privilege-system.xml =================================================================== --- trunk/refman-6.0/dba-privilege-system.xml 2009-01-14 21:59:10 UTC (rev 13193) +++ trunk/refman-6.0/dba-privilege-system.xml 2009-01-14 21:59:17 UTC (rev 13194) Changed blocks: 5, Lines Added: 42, Lines Deleted: 43; 5886 bytes @@ -2253,7 +2253,7 @@ checks the user's table and column privileges in the <literal>tables_priv</literal> and <literal>columns_priv</literal> tables, adds those to the user's privileges, and allows or denies - access based on the result. For stored routine operations, the + access based on the result. For stored-routine operations, the server uses the <literal>procs_priv</literal> table rather than <literal>tables_priv</literal> and <literal>columns_priv</literal>. @@ -2305,9 +2305,8 @@ <literal role="stmt">REVOKE</literal> statements, so it is unused in most MySQL installations. If you modify it directly, you can use it for some specialized purposes, such as to maintain a list - of secure servers. For example, at TcX, the - <literal>host</literal> table contains a list of all machines on - the local network. These are granted all privileges. + of secure servers on the local network that are granted all + privileges. </para> <para> @@ -2366,10 +2365,39 @@ </para> <para> - When the server reloads the grant tables, privileges for existing - client connections are affected as follows: + If you modify the grant tables indirectly using account-management + statements such as <literal role="stmt">GRANT</literal>, + <literal role="stmt">REVOKE</literal>, or <literal role="stmt">SET + PASSWORD</literal>, the server notices these changes and loads the + grant tables into memory again immediately. </para> + <para> + If you modify the grant tables directly using statements such as + <literal role="stmt">INSERT</literal>, + <literal role="stmt">UPDATE</literal>, or + <literal role="stmt">DELETE</literal>, your changes have no effect + on privilege checking until you either restart the server or tell + it to reload the tables. If you change the grant tables directly + but forget to reload them, your changes have <emphasis>no + effect</emphasis> until you restart the server. This may leave you + wondering why your changes do not seem to make any difference! + </para> + + <para> + To tell the sever to reload the grant tables, perform a + flush-privileges operation. This can be done by issuing a + <literal role="stmt" condition="flush">FLUSH PRIVILEGES</literal> + statement or by executing a <command>mysqladmin + flush-privileges</command> or <command>mysqladmin reload</command> + command. + </para> + + <para> + When the server reloads the grant tables, privileges for each + existing client connection are affected as follows: + </para> + <itemizedlist> <listitem> @@ -2381,60 +2409,31 @@ <listitem> <para> - Database privilege changes take effect at the next - <literal>USE <replaceable>db_name</replaceable></literal> - statement. + Database privilege changes take effect the next time the + client executes a <literal>USE + <replaceable>db_name</replaceable></literal> statement. </para> <note> <para> Client applications may cache the database name; thus, this effect may not be visible to them without actually changing - to a different database or executing a - <literal role="stmt" condition="flush">FLUSH - PRIVILEGES</literal> statement. + to a different database or flushing the privileges. </para> </note> </listitem> <listitem> <para> - Changes to global privileges and passwords take effect the - next time the client connects. + Global privileges and passwords are unaffected for a connected + client. These changes take effect only for subsequent + connections. </para> </listitem> </itemizedlist> <para> - If you modify the grant tables indirectly using statements such as - <literal role="stmt">GRANT</literal>, - <literal role="stmt">REVOKE</literal>, or <literal role="stmt">SET - PASSWORD</literal>, the server notices these changes and loads the - grant tables into memory again immediately. - </para> - - <para> - If you modify the grant tables directly using statements such as - <literal role="stmt">INSERT</literal>, - <literal role="stmt">UPDATE</literal>, or - <literal role="stmt">DELETE</literal>, your changes have no effect - on privilege checking until you either restart the server or tell - it to reload the tables. To reload the grant tables manually, - issue a <literal role="stmt" condition="flush">FLUSH - PRIVILEGES</literal> statement or execute a <command>mysqladmin - flush-privileges</command> or <command>mysqladmin reload</command> - command. - </para> - - <para> - If you change the grant tables directly but forget to reload them, - your changes have <emphasis>no effect</emphasis> until you restart - the server. This may leave you wondering why your changes do not - seem to make any difference! - </para> - - <para> If the server is started with the <option>--skip-grant-tables</option> option, it does not read the grant tables or implement any access control. Anyone can connect @@ -2446,7 +2445,7 @@ <section id="access-denied"> - <title>Causes of <literal>Access denied</literal> Errors</title> + <title>Causes of Access-Denied Errors</title> <remark role="todo"> some of these items apply only to old systems and are now more of
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r13194 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul.dubois | 14 Jan 2009 |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.768 sec. using MySQL 5.1.14-beta-log