Author: paul
Date: 2009-03-25 17:42:35 +0100 (Wed, 25 Mar 2009)
New Revision: 14367
Log:
r39900@frost: paul | 2009-03-25 11:40:03 -0500
Access control: General revisions
Modified:
trunk/refman-4.1/dba-privilege-system.xml
trunk/refman-4.1/programs-client.xml
trunk/refman-5.0/dba-privilege-system.xml
trunk/refman-5.0/programs-client-core.xml
trunk/refman-5.1/dba-privilege-system.xml
trunk/refman-5.1/programs-client-core.xml
trunk/refman-6.0/dba-privilege-system.xml
trunk/refman-6.0/programs-client-core.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:41755
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:39899
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:37251
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:41755
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:39900
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:37251
Modified: trunk/refman-4.1/dba-privilege-system.xml
===================================================================
--- trunk/refman-4.1/dba-privilege-system.xml 2009-03-25 16:42:22 UTC (rev 14366)
+++ trunk/refman-4.1/dba-privilege-system.xml 2009-03-25 16:42:35 UTC (rev 14367)
Changed blocks: 12, Lines Added: 132, Lines Deleted: 165; 13124 bytes
@@ -53,6 +53,38 @@
</para>
<para>
+ There are some things that you cannot do with the MySQL privilege
+ system:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ You cannot explicitly specify that a given user should be denied
+ access. That is, you cannot explicitly match a user and then
+ refuse the connection.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ You cannot specify that a user has privileges to create or drop
+ tables in a database but not to create or drop the database
+ itself.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A password applies globally to an account. You cannot associate
+ a password with a specific object such as a database or table.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
The user interface to the MySQL privilege system consists of SQL
statements such as <literal role="stmt">GRANT</literal> and
<literal role="stmt">REVOKE</literal>. See
@@ -136,38 +168,6 @@
</para>
<para>
- There are some things that you cannot do with the MySQL privilege
- system:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- You cannot explicitly specify that a given user should be denied
- access. That is, you cannot explicitly match a user and then
- refuse the connection.
- </para>
- </listitem>
-
- <listitem>
- <para>
- You cannot specify that a user has privileges to create or drop
- tables in a database but not to create or drop the database
- itself.
- </para>
- </listitem>
-
- <listitem>
- <para>
- A password applies globally to an account. You cannot associate
- a password with a specific object such as a database or table.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
For general security-related advice, see <xref linkend="security"/>.
For help in diagnosing privilege-related problems, see
<xref linkend="access-denied"/>.
@@ -762,7 +762,7 @@
<section id="grant-table-structure">
- <title>The Privilege System Grant Tables</title>
+ <title>Privilege System Grant Tables</title>
<indexterm>
<primary>grant tables</primary>
@@ -831,6 +831,86 @@
</itemizedlist>
<para>
+ The server uses the grant tables in the following manner:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The <literal>user</literal> table scope columns determine
+ whether to reject or allow incoming connections. For allowed
+ connections, any privileges granted in the
+ <literal>user</literal> table indicate the user's global
+ (superuser) privileges. Any privilege granted in this table
+ applies to <emphasis>all</emphasis> databases on the server.
+ </para>
+
+ <note>
+ <para>
+ Because any global privilege is considered a privilege for
+ all databases, any global privilege enables a user to see
+ all database names with <literal role="stmt">SHOW
+ DATABASES</literal>.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>db</literal> table scope columns determine which
+ users can access which databases from which hosts. The
+ privilege columns determine which operations are allowed. A
+ privilege granted at the database level applies to the
+ database and to all objects in the database, such as tables
+ and stored programs.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>host</literal> table is used in conjunction with
+ the <literal>db</literal> table when you want a given
+ <literal>db</literal> table row to apply to several hosts. For
+ example, if you want a user to be able to use a database from
+ several hosts in your network, leave the
+ <literal>Host</literal> value empty in the user's
+ <literal>db</literal> table row, then populate the
+ <literal>host</literal> table with a row for each of those
+ hosts. This mechanism is described more detail in
+ <xref linkend="request-access"/>.
+ </para>
+
+ <note>
+ <para>
+ The <literal>host</literal> table must be modified directly
+ with statements such as
+ <literal role="stmt">INSERT</literal>,
+ <literal role="stmt">UPDATE</literal>, and
+ <literal role="stmt">DELETE</literal>. It is not affected by
+ statements such as <literal role="stmt">GRANT</literal> and
+ <literal role="stmt">REVOKE</literal> that modify the grant
+ tables indirectly. Most MySQL installations need not use
+ this table at all.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>tables_priv</literal> and
+ <literal>columns_priv</literal> tables are similar to the
+ <literal>db</literal> table, but are more fine-grained: They
+ apply at the table and column levels rather than at the
+ database level. A privilege granted at the table level applies
+ to the table and to all its columns. A privilege granted at
+ the column level applies only to a specific column.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
The server uses the <literal>user</literal>,
<literal>db</literal>, and <literal>host</literal> tables in the
<literal>mysql</literal> database at both the first and second
@@ -1233,86 +1313,6 @@
</informaltable>
<para>
- Briefly, the server uses the grant tables in the following manner:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- The <literal>user</literal> table scope columns determine
- whether to reject or allow incoming connections. For allowed
- connections, any privileges granted in the
- <literal>user</literal> table indicate the user's global
- (superuser) privileges. Any privilege granted in this table
- applies to <emphasis>all</emphasis> databases on the server.
- </para>
-
- <note>
- <para>
- Because any global privilege is considered a privilege for
- all databases, any global privilege enables a user to see
- all database names with <literal role="stmt">SHOW
- DATABASES</literal>.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- The <literal>db</literal> table scope columns determine which
- users can access which databases from which hosts. The
- privilege columns determine which operations are allowed. A
- privilege granted at the database level applies to the
- database and to all objects in the database, such as tables
- and stored programs.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The <literal>host</literal> table is used in conjunction with
- the <literal>db</literal> table when you want a given
- <literal>db</literal> table row to apply to several hosts. For
- example, if you want a user to be able to use a database from
- several hosts in your network, leave the
- <literal>Host</literal> value empty in the user's
- <literal>db</literal> table row, then populate the
- <literal>host</literal> table with a row for each of those
- hosts. This mechanism is described more detail in
- <xref linkend="request-access"/>.
- </para>
-
- <note>
- <para>
- The <literal>host</literal> table must be modified directly
- with statements such as
- <literal role="stmt">INSERT</literal>,
- <literal role="stmt">UPDATE</literal>, and
- <literal role="stmt">DELETE</literal>. It is not affected by
- statements such as <literal role="stmt">GRANT</literal> and
- <literal role="stmt">REVOKE</literal> that modify the grant
- tables indirectly. Most MySQL installations need not use
- this table at all.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- The <literal>tables_priv</literal> and
- <literal>columns_priv</literal> tables are similar to the
- <literal>db</literal> table, but are more fine-grained: They
- apply at the table and column levels rather than at the
- database level. A privilege granted at the table level applies
- to the table and to all its columns. A privilege granted at
- the column level applies only to a specific column.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
Administrative privileges (such as
<literal role="priv">RELOAD</literal> or
<literal role="priv">SHUTDOWN</literal>) are specified only in the
@@ -1568,20 +1568,6 @@
</programlisting>
</listitem>
- <listitem>
- <para>
- With one exception, a blank <literal>Host</literal> value in
- the grant tables is the same as <literal>'%'</literal>. The
- exception is that A blank <literal>Host</literal> value in a
- <literal>db</literal> table row means that its privileges
- should be combined with those in the row in the
- <literal>host</literal> table that matches the client host
- name. The privileges are combined using an AND (intersection)
- operation, not OR (union). <xref linkend="request-access"/>,
- discusses use of the <literal>host</literal> table further.
- </para>
- </listitem>
-
</itemizedlist>
<para>
@@ -1631,8 +1617,12 @@
<literal role="func">PASSWORD()</literal> function). The encrypted
password then is used during the connection process when checking
whether the password is correct. (This is done without the
- encrypted password ever traveling over the connection.) From
- MySQL's point of view, the encrypted password is the
+ encrypted password ever traveling over the connection.) See
+ <xref linkend="user-names"/>.
+ </para>
+
+ <para>
+ From MySQL's point of view, the encrypted password is the
<emphasis>real</emphasis> password, so you should never give
anyone access to it. In particular, <emphasis>do not give
non-administrative users read access to tables in the
@@ -1640,15 +1630,6 @@
</para>
<para>
- From version 4.1 on, MySQL employs a stronger authentication
- method that has better password protection during the connection
- process than in earlier versions. It is secure even if TCP/IP
- packets are sniffed or the <literal>mysql</literal> database is
- captured. <xref linkend="password-hashing"/>, discusses password
- encryption further.
- </para>
-
- <para>
The following table shows how various combinations of
<literal>Host</literal> and <literal>User</literal> values in the
<literal>user</literal> table apply to incoming connections.
@@ -1976,6 +1957,15 @@
<listitem>
<para>
+ A blank <literal>User</literal> value in the
+ <literal>db</literal> table matches the anonymous user. A
+ non-blank value matches literally; there are no wildcards in
+ user names.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
The wildcard characters <quote><literal>%</literal></quote>
and <quote><literal>_</literal></quote> can be used in the
<literal>Host</literal> and <literal>Db</literal> columns of
@@ -2017,13 +2007,6 @@
</para>
</listitem>
- <listitem>
- <para>
- A blank <literal>User</literal> value in the
- <literal>db</literal> table matches the anonymous user.
- </para>
- </listitem>
-
</itemizedlist>
<indexterm>
@@ -2275,6 +2258,10 @@
+--------------------+----+-
</programlisting>
+ </section>
+
+ <section id="privilege-changes">
+
<indexterm>
<primary>privilege</primary>
<secondary>changes</secondary>
@@ -2284,26 +2271,6 @@
<primary>changes to privileges</primary>
</indexterm>
- <indexterm>
- <primary>tables</primary>
- <secondary>grant</secondary>
- </indexterm>
-
- <indexterm>
- <primary>grant tables</primary>
- </indexterm>
-
- <para>
- Naturally, you should always test your changes to the grant tables
- (for example, by using <literal role="stmt">SHOW GRANTS</literal>)
- to make sure that your access privileges are actually set up the
- way you think they are.
- </para>
-
- </section>
-
- <section id="privilege-changes">
-
<title>When Privilege Changes Take Effect</title>
<para>
Modified: trunk/refman-4.1/programs-client.xml
===================================================================
--- trunk/refman-4.1/programs-client.xml 2009-03-25 16:42:22 UTC (rev 14366)
+++ trunk/refman-4.1/programs-client.xml 2009-03-25 16:42:35 UTC (rev 14367)
Changed blocks: 1, Lines Added: 7, Lines Deleted: 0; 808 bytes
@@ -1553,6 +1553,13 @@
</para>
<para>
+ The <filename>.mysql_history</filename> should be protected with
+ a restrictive access mode because sensitive information might be
+ written to it, such as the text of SQL statements that contain
+ passwords. See <xref linkend="password-security-user"/>.
+ </para>
+
+ <para>
If you do not want to maintain a history file, first remove
<filename>.mysql_history</filename> if it exists, and then use
either of the following techniques:
Modified: trunk/refman-5.0/dba-privilege-system.xml
===================================================================
--- trunk/refman-5.0/dba-privilege-system.xml 2009-03-25 16:42:22 UTC (rev 14366)
+++ trunk/refman-5.0/dba-privilege-system.xml 2009-03-25 16:42:35 UTC (rev 14367)
Changed blocks: 12, Lines Added: 143, Lines Deleted: 177; 13937 bytes
@@ -53,6 +53,39 @@
</para>
<para>
+ There are some things that you cannot do with the MySQL privilege
+ system:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ You cannot explicitly specify that a given user should be denied
+ access. That is, you cannot explicitly match a user and then
+ refuse the connection.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ You cannot specify that a user has privileges to create or drop
+ tables in a database but not to create or drop the database
+ itself.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A password applies globally to an account. You cannot associate
+ a password with a specific object such as a database, table, or
+ routine.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
The user interface to the MySQL privilege system consists of SQL
statements such as <literal role="stmt">CREATE USER</literal>,
<literal role="stmt">GRANT</literal>, and
@@ -137,39 +170,6 @@
</para>
<para>
- There are some things that you cannot do with the MySQL privilege
- system:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- You cannot explicitly specify that a given user should be denied
- access. That is, you cannot explicitly match a user and then
- refuse the connection.
- </para>
- </listitem>
-
- <listitem>
- <para>
- You cannot specify that a user has privileges to create or drop
- tables in a database but not to create or drop the database
- itself.
- </para>
- </listitem>
-
- <listitem>
- <para>
- A password applies globally to an account. You cannot associate
- a password with a specific object such as a database, table, or
- routine.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
For general security-related advice, see <xref linkend="security"/>.
For help in diagnosing privilege-related problems, see
<xref linkend="access-denied"/>.
@@ -862,7 +862,7 @@
<section id="grant-table-structure">
- <title>The Privilege System Grant Tables</title>
+ <title>Privilege System Grant Tables</title>
<indexterm>
<primary>grant tables</primary>
@@ -931,6 +931,96 @@
</itemizedlist>
<para>
+ The server uses the grant tables in the following manner:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The <literal>user</literal> table scope columns determine
+ whether to reject or allow incoming connections. For allowed
+ connections, any privileges granted in the
+ <literal>user</literal> table indicate the user's global
+ (superuser) privileges. Any privilege granted in this table
+ applies to <emphasis>all</emphasis> databases on the server.
+ </para>
+
+ <note>
+ <para>
+ Because any global privilege is considered a privilege for
+ all databases, any global privilege enables a user to see
+ all database names with <literal role="stmt">SHOW
+ DATABASES</literal> or by examining the
+ <literal role="is">SCHEMATA</literal> table of
+ <literal>INFORMATION_SCHEMA</literal>.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>db</literal> table scope columns determine which
+ users can access which databases from which hosts. The
+ privilege columns determine which operations are allowed. A
+ privilege granted at the database level applies to the
+ database and to all objects in the database, such as tables
+ and stored programs.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>host</literal> table is used in conjunction with
+ the <literal>db</literal> table when you want a given
+ <literal>db</literal> table row to apply to several hosts. For
+ example, if you want a user to be able to use a database from
+ several hosts in your network, leave the
+ <literal>Host</literal> value empty in the user's
+ <literal>db</literal> table row, then populate the
+ <literal>host</literal> table with a row for each of those
+ hosts. This mechanism is described more detail in
+ <xref linkend="request-access"/>.
+ </para>
+
+ <note>
+ <para>
+ The <literal>host</literal> table must be modified directly
+ with statements such as
+ <literal role="stmt">INSERT</literal>,
+ <literal role="stmt">UPDATE</literal>, and
+ <literal role="stmt">DELETE</literal>. It is not affected by
+ statements such as <literal role="stmt">GRANT</literal> and
+ <literal role="stmt">REVOKE</literal> that modify the grant
+ tables indirectly. Most MySQL installations need not use
+ this table at all.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>tables_priv</literal> and
+ <literal>columns_priv</literal> tables are similar to the
+ <literal>db</literal> table, but are more fine-grained: They
+ apply at the table and column levels rather than at the
+ database level. A privilege granted at the table level applies
+ to the table and to all its columns. A privilege granted at
+ the column level applies only to a specific column.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>procs_priv</literal> table applies to stored
+ routines. A privilege granted at the routine level applies
+ only to a single routine.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
The server uses the <literal>user</literal>,
<literal>db</literal>, and <literal>host</literal> tables in the
<literal>mysql</literal> database at both the first and second
@@ -1421,96 +1511,6 @@
</informaltable>
<para>
- Briefly, the server uses the grant tables in the following manner:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- The <literal>user</literal> table scope columns determine
- whether to reject or allow incoming connections. For allowed
- connections, any privileges granted in the
- <literal>user</literal> table indicate the user's global
- (superuser) privileges. Any privilege granted in this table
- applies to <emphasis>all</emphasis> databases on the server.
- </para>
-
- <note>
- <para>
- Because any global privilege is considered a privilege for
- all databases, any global privilege enables a user to see
- all database names with <literal role="stmt">SHOW
- DATABASES</literal> or by examining the
- <literal role="is">SCHEMATA</literal> table of
- <literal>INFORMATION_SCHEMA</literal>.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- The <literal>db</literal> table scope columns determine which
- users can access which databases from which hosts. The
- privilege columns determine which operations are allowed. A
- privilege granted at the database level applies to the
- database and to all objects in the database, such as tables
- and stored programs.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The <literal>host</literal> table is used in conjunction with
- the <literal>db</literal> table when you want a given
- <literal>db</literal> table row to apply to several hosts. For
- example, if you want a user to be able to use a database from
- several hosts in your network, leave the
- <literal>Host</literal> value empty in the user's
- <literal>db</literal> table row, then populate the
- <literal>host</literal> table with a row for each of those
- hosts. This mechanism is described more detail in
- <xref linkend="request-access"/>.
- </para>
-
- <note>
- <para>
- The <literal>host</literal> table must be modified directly
- with statements such as
- <literal role="stmt">INSERT</literal>,
- <literal role="stmt">UPDATE</literal>, and
- <literal role="stmt">DELETE</literal>. It is not affected by
- statements such as <literal role="stmt">GRANT</literal> and
- <literal role="stmt">REVOKE</literal> that modify the grant
- tables indirectly. Most MySQL installations need not use
- this table at all.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- The <literal>tables_priv</literal> and
- <literal>columns_priv</literal> tables are similar to the
- <literal>db</literal> table, but are more fine-grained: They
- apply at the table and column levels rather than at the
- database level. A privilege granted at the table level applies
- to the table and to all its columns. A privilege granted at
- the column level applies only to a specific column.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The <literal>procs_priv</literal> table applies to stored
- routines. A privilege granted at the routine level applies
- only to a single routine.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
Administrative privileges (such as
<literal role="priv">RELOAD</literal> or
<literal role="priv">SHUTDOWN</literal>) are specified only in the
@@ -1756,20 +1756,6 @@
</programlisting>
</listitem>
- <listitem>
- <para>
- With one exception, a blank <literal>Host</literal> value in
- the grant tables is the same as <literal>'%'</literal>. The
- exception is that A blank <literal>Host</literal> value in a
- <literal>db</literal> table row means that its privileges
- should be combined with those in the row in the
- <literal>host</literal> table that matches the client host
- name. The privileges are combined using an AND (intersection)
- operation, not OR (union). <xref linkend="request-access"/>,
- discusses use of the <literal>host</literal> table further.
- </para>
- </listitem>
-
</itemizedlist>
<para>
@@ -1819,8 +1805,12 @@
<literal role="func">PASSWORD()</literal> function). The encrypted
password then is used during the connection process when checking
whether the password is correct. (This is done without the
- encrypted password ever traveling over the connection.) From
- MySQL's point of view, the encrypted password is the
+ encrypted password ever traveling over the connection.) See
+ <xref linkend="user-names"/>.
+ </para>
+
+ <para>
+ From MySQL's point of view, the encrypted password is the
<emphasis>real</emphasis> password, so you should never give
anyone access to it. In particular, <emphasis>do not give
non-administrative users read access to tables in the
@@ -1828,16 +1818,6 @@
</para>
<para>
- MySQL ¤t-series; employs the stronger authentication method
- (first implemented in MySQL 4.1) that has better password
- protection during the connection process than in earlier versions.
- It is secure even if TCP/IP packets are sniffed or the
- <literal>mysql</literal> database is captured.
- <xref linkend="password-hashing"/>, discusses password encryption
- further.
- </para>
-
- <para>
The following table shows how various combinations of
<literal>Host</literal> and <literal>User</literal> values in the
<literal>user</literal> table apply to incoming connections.
@@ -2166,6 +2146,15 @@
<listitem>
<para>
+ A blank <literal>User</literal> value in the
+ <literal>db</literal> table matches the anonymous user. A
+ non-blank value matches literally; there are no wildcards in
+ user names.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
The wildcard characters <quote><literal>%</literal></quote>
and <quote><literal>_</literal></quote> can be used in the
<literal>Host</literal> and <literal>Db</literal> columns of
@@ -2207,13 +2196,6 @@
</para>
</listitem>
- <listitem>
- <para>
- A blank <literal>User</literal> value in the
- <literal>db</literal> table matches the anonymous user.
- </para>
- </listitem>
-
</itemizedlist>
<indexterm>
@@ -2472,6 +2454,10 @@
+--------------------+----+-
</programlisting>
+ </section>
+
+ <section id="privilege-changes">
+
<indexterm>
<primary>privilege</primary>
<secondary>changes</secondary>
@@ -2481,26 +2467,6 @@
<primary>changes to privileges</primary>
</indexterm>
- <indexterm>
- <primary>tables</primary>
- <secondary>grant</secondary>
- </indexterm>
-
- <indexterm>
- <primary>grant tables</primary>
- </indexterm>
-
- <para>
- Naturally, you should always test your changes to the grant tables
- (for example, by using <literal role="stmt">SHOW GRANTS</literal>)
- to make sure that your access privileges are actually set up the
- way you think they are.
- </para>
-
- </section>
-
- <section id="privilege-changes">
-
<title>When Privilege Changes Take Effect</title>
<para>
Modified: trunk/refman-5.0/programs-client-core.xml
===================================================================
--- trunk/refman-5.0/programs-client-core.xml 2009-03-25 16:42:22 UTC (rev 14366)
+++ trunk/refman-5.0/programs-client-core.xml 2009-03-25 16:42:35 UTC (rev 14367)
Changed blocks: 1, Lines Added: 7, Lines Deleted: 0; 823 bytes
@@ -1691,6 +1691,13 @@
</para>
<para>
+ The <filename>.mysql_history</filename> should be protected with
+ a restrictive access mode because sensitive information might be
+ written to it, such as the text of SQL statements that contain
+ passwords. See <xref linkend="password-security-user"/>.
+ </para>
+
+ <para>
If you do not want to maintain a history file, first remove
<filename>.mysql_history</filename> if it exists, and then use
either of the following techniques:
Modified: trunk/refman-5.1/dba-privilege-system.xml
===================================================================
--- trunk/refman-5.1/dba-privilege-system.xml 2009-03-25 16:42:22 UTC (rev 14366)
+++ trunk/refman-5.1/dba-privilege-system.xml 2009-03-25 16:42:35 UTC (rev 14367)
Changed blocks: 12, Lines Added: 143, Lines Deleted: 177; 13937 bytes
@@ -53,6 +53,39 @@
</para>
<para>
+ There are some things that you cannot do with the MySQL privilege
+ system:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ You cannot explicitly specify that a given user should be denied
+ access. That is, you cannot explicitly match a user and then
+ refuse the connection.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ You cannot specify that a user has privileges to create or drop
+ tables in a database but not to create or drop the database
+ itself.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A password applies globally to an account. You cannot associate
+ a password with a specific object such as a database, table, or
+ routine.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
The user interface to the MySQL privilege system consists of SQL
statements such as <literal role="stmt">CREATE USER</literal>,
<literal role="stmt">GRANT</literal>, and
@@ -137,39 +170,6 @@
</para>
<para>
- There are some things that you cannot do with the MySQL privilege
- system:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- You cannot explicitly specify that a given user should be denied
- access. That is, you cannot explicitly match a user and then
- refuse the connection.
- </para>
- </listitem>
-
- <listitem>
- <para>
- You cannot specify that a user has privileges to create or drop
- tables in a database but not to create or drop the database
- itself.
- </para>
- </listitem>
-
- <listitem>
- <para>
- A password applies globally to an account. You cannot associate
- a password with a specific object such as a database, table, or
- routine.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
For general security-related advice, see <xref linkend="security"/>.
For help in diagnosing privilege-related problems, see
<xref linkend="access-denied"/>.
@@ -898,7 +898,7 @@
<section id="grant-table-structure">
- <title>The Privilege System Grant Tables</title>
+ <title>Privilege System Grant Tables</title>
<indexterm>
<primary>grant tables</primary>
@@ -967,6 +967,96 @@
</itemizedlist>
<para>
+ The server uses the grant tables in the following manner:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The <literal>user</literal> table scope columns determine
+ whether to reject or allow incoming connections. For allowed
+ connections, any privileges granted in the
+ <literal>user</literal> table indicate the user's global
+ (superuser) privileges. Any privilege granted in this table
+ applies to <emphasis>all</emphasis> databases on the server.
+ </para>
+
+ <note>
+ <para>
+ Because any global privilege is considered a privilege for
+ all databases, any global privilege enables a user to see
+ all database names with <literal role="stmt">SHOW
+ DATABASES</literal> or by examining the
+ <literal role="is">SCHEMATA</literal> table of
+ <literal>INFORMATION_SCHEMA</literal>.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>db</literal> table scope columns determine which
+ users can access which databases from which hosts. The
+ privilege columns determine which operations are allowed. A
+ privilege granted at the database level applies to the
+ database and to all objects in the database, such as tables
+ and stored programs.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>host</literal> table is used in conjunction with
+ the <literal>db</literal> table when you want a given
+ <literal>db</literal> table row to apply to several hosts. For
+ example, if you want a user to be able to use a database from
+ several hosts in your network, leave the
+ <literal>Host</literal> value empty in the user's
+ <literal>db</literal> table row, then populate the
+ <literal>host</literal> table with a row for each of those
+ hosts. This mechanism is described more detail in
+ <xref linkend="request-access"/>.
+ </para>
+
+ <note>
+ <para>
+ The <literal>host</literal> table must be modified directly
+ with statements such as
+ <literal role="stmt">INSERT</literal>,
+ <literal role="stmt">UPDATE</literal>, and
+ <literal role="stmt">DELETE</literal>. It is not affected by
+ statements such as <literal role="stmt">GRANT</literal> and
+ <literal role="stmt">REVOKE</literal> that modify the grant
+ tables indirectly. Most MySQL installations need not use
+ this table at all.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>tables_priv</literal> and
+ <literal>columns_priv</literal> tables are similar to the
+ <literal>db</literal> table, but are more fine-grained: They
+ apply at the table and column levels rather than at the
+ database level. A privilege granted at the table level applies
+ to the table and to all its columns. A privilege granted at
+ the column level applies only to a specific column.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>procs_priv</literal> table applies to stored
+ routines. A privilege granted at the routine level applies
+ only to a single routine.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
The server uses the <literal>user</literal>,
<literal>db</literal>, and <literal>host</literal> tables in the
<literal>mysql</literal> database at both the first and second
@@ -1453,96 +1543,6 @@
</informaltable>
<para>
- Briefly, the server uses the grant tables in the following manner:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- The <literal>user</literal> table scope columns determine
- whether to reject or allow incoming connections. For allowed
- connections, any privileges granted in the
- <literal>user</literal> table indicate the user's global
- (superuser) privileges. Any privilege granted in this table
- applies to <emphasis>all</emphasis> databases on the server.
- </para>
-
- <note>
- <para>
- Because any global privilege is considered a privilege for
- all databases, any global privilege enables a user to see
- all database names with <literal role="stmt">SHOW
- DATABASES</literal> or by examining the
- <literal role="is">SCHEMATA</literal> table of
- <literal>INFORMATION_SCHEMA</literal>.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- The <literal>db</literal> table scope columns determine which
- users can access which databases from which hosts. The
- privilege columns determine which operations are allowed. A
- privilege granted at the database level applies to the
- database and to all objects in the database, such as tables
- and stored programs.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The <literal>host</literal> table is used in conjunction with
- the <literal>db</literal> table when you want a given
- <literal>db</literal> table row to apply to several hosts. For
- example, if you want a user to be able to use a database from
- several hosts in your network, leave the
- <literal>Host</literal> value empty in the user's
- <literal>db</literal> table row, then populate the
- <literal>host</literal> table with a row for each of those
- hosts. This mechanism is described more detail in
- <xref linkend="request-access"/>.
- </para>
-
- <note>
- <para>
- The <literal>host</literal> table must be modified directly
- with statements such as
- <literal role="stmt">INSERT</literal>,
- <literal role="stmt">UPDATE</literal>, and
- <literal role="stmt">DELETE</literal>. It is not affected by
- statements such as <literal role="stmt">GRANT</literal> and
- <literal role="stmt">REVOKE</literal> that modify the grant
- tables indirectly. Most MySQL installations need not use
- this table at all.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- The <literal>tables_priv</literal> and
- <literal>columns_priv</literal> tables are similar to the
- <literal>db</literal> table, but are more fine-grained: They
- apply at the table and column levels rather than at the
- database level. A privilege granted at the table level applies
- to the table and to all its columns. A privilege granted at
- the column level applies only to a specific column.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The <literal>procs_priv</literal> table applies to stored
- routines. A privilege granted at the routine level applies
- only to a single routine.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
Administrative privileges (such as
<literal role="priv">RELOAD</literal> or
<literal role="priv">SHUTDOWN</literal>) are specified only in the
@@ -1788,20 +1788,6 @@
</programlisting>
</listitem>
- <listitem>
- <para>
- With one exception, a blank <literal>Host</literal> value in
- the grant tables is the same as <literal>'%'</literal>. The
- exception is that A blank <literal>Host</literal> value in a
- <literal>db</literal> table row means that its privileges
- should be combined with those in the row in the
- <literal>host</literal> table that matches the client host
- name. The privileges are combined using an AND (intersection)
- operation, not OR (union). <xref linkend="request-access"/>,
- discusses use of the <literal>host</literal> table further.
- </para>
- </listitem>
-
</itemizedlist>
<para>
@@ -1851,8 +1837,12 @@
<literal role="func">PASSWORD()</literal> function). The encrypted
password then is used during the connection process when checking
whether the password is correct. (This is done without the
- encrypted password ever traveling over the connection.) From
- MySQL's point of view, the encrypted password is the
+ encrypted password ever traveling over the connection.) See
+ <xref linkend="user-names"/>.
+ </para>
+
+ <para>
+ From MySQL's point of view, the encrypted password is the
<emphasis>real</emphasis> password, so you should never give
anyone access to it. In particular, <emphasis>do not give
non-administrative users read access to tables in the
@@ -1860,16 +1850,6 @@
</para>
<para>
- MySQL ¤t-series; employs the stronger authentication method
- (first implemented in MySQL 4.1) that has better password
- protection during the connection process than in earlier versions.
- It is secure even if TCP/IP packets are sniffed or the
- <literal>mysql</literal> database is captured.
- <xref linkend="password-hashing"/>, discusses password encryption
- further.
- </para>
-
- <para>
The following table shows how various combinations of
<literal>Host</literal> and <literal>User</literal> values in the
<literal>user</literal> table apply to incoming connections.
@@ -2198,6 +2178,15 @@
<listitem>
<para>
+ A blank <literal>User</literal> value in the
+ <literal>db</literal> table matches the anonymous user. A
+ non-blank value matches literally; there are no wildcards in
+ user names.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
The wildcard characters <quote><literal>%</literal></quote>
and <quote><literal>_</literal></quote> can be used in the
<literal>Host</literal> and <literal>Db</literal> columns of
@@ -2239,13 +2228,6 @@
</para>
</listitem>
- <listitem>
- <para>
- A blank <literal>User</literal> value in the
- <literal>db</literal> table matches the anonymous user.
- </para>
- </listitem>
-
</itemizedlist>
<indexterm>
@@ -2504,6 +2486,10 @@
+--------------------+----+-
</programlisting>
+ </section>
+
+ <section id="privilege-changes">
+
<indexterm>
<primary>privilege</primary>
<secondary>changes</secondary>
@@ -2513,26 +2499,6 @@
<primary>changes to privileges</primary>
</indexterm>
- <indexterm>
- <primary>tables</primary>
- <secondary>grant</secondary>
- </indexterm>
-
- <indexterm>
- <primary>grant tables</primary>
- </indexterm>
-
- <para>
- Naturally, you should always test your changes to the grant tables
- (for example, by using <literal role="stmt">SHOW GRANTS</literal>)
- to make sure that your access privileges are actually set up the
- way you think they are.
- </para>
-
- </section>
-
- <section id="privilege-changes">
-
<title>When Privilege Changes Take Effect</title>
<para>
Modified: trunk/refman-5.1/programs-client-core.xml
===================================================================
--- trunk/refman-5.1/programs-client-core.xml 2009-03-25 16:42:22 UTC (rev 14366)
+++ trunk/refman-5.1/programs-client-core.xml 2009-03-25 16:42:35 UTC (rev 14367)
Changed blocks: 1, Lines Added: 7, Lines Deleted: 0; 823 bytes
@@ -1734,6 +1734,13 @@
</para>
<para>
+ The <filename>.mysql_history</filename> should be protected with
+ a restrictive access mode because sensitive information might be
+ written to it, such as the text of SQL statements that contain
+ passwords. See <xref linkend="password-security-user"/>.
+ </para>
+
+ <para>
If you do not want to maintain a history file, first remove
<filename>.mysql_history</filename> if it exists, and then use
either of the following techniques:
Modified: trunk/refman-6.0/dba-privilege-system.xml
===================================================================
--- trunk/refman-6.0/dba-privilege-system.xml 2009-03-25 16:42:22 UTC (rev 14366)
+++ trunk/refman-6.0/dba-privilege-system.xml 2009-03-25 16:42:35 UTC (rev 14367)
Changed blocks: 12, Lines Added: 143, Lines Deleted: 177; 13937 bytes
@@ -53,6 +53,39 @@
</para>
<para>
+ There are some things that you cannot do with the MySQL privilege
+ system:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ You cannot explicitly specify that a given user should be denied
+ access. That is, you cannot explicitly match a user and then
+ refuse the connection.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ You cannot specify that a user has privileges to create or drop
+ tables in a database but not to create or drop the database
+ itself.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A password applies globally to an account. You cannot associate
+ a password with a specific object such as a database, table, or
+ routine.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
The user interface to the MySQL privilege system consists of SQL
statements such as <literal role="stmt">CREATE USER</literal>,
<literal role="stmt">GRANT</literal>, and
@@ -137,39 +170,6 @@
</para>
<para>
- There are some things that you cannot do with the MySQL privilege
- system:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- You cannot explicitly specify that a given user should be denied
- access. That is, you cannot explicitly match a user and then
- refuse the connection.
- </para>
- </listitem>
-
- <listitem>
- <para>
- You cannot specify that a user has privileges to create or drop
- tables in a database but not to create or drop the database
- itself.
- </para>
- </listitem>
-
- <listitem>
- <para>
- A password applies globally to an account. You cannot associate
- a password with a specific object such as a database, table, or
- routine.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
For general security-related advice, see <xref linkend="security"/>.
For help in diagnosing privilege-related problems, see
<xref linkend="access-denied"/>.
@@ -902,7 +902,7 @@
<section id="grant-table-structure">
- <title>The Privilege System Grant Tables</title>
+ <title>Privilege System Grant Tables</title>
<indexterm>
<primary>grant tables</primary>
@@ -971,6 +971,96 @@
</itemizedlist>
<para>
+ The server uses the grant tables in the following manner:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The <literal>user</literal> table scope columns determine
+ whether to reject or allow incoming connections. For allowed
+ connections, any privileges granted in the
+ <literal>user</literal> table indicate the user's global
+ (superuser) privileges. Any privilege granted in this table
+ applies to <emphasis>all</emphasis> databases on the server.
+ </para>
+
+ <note>
+ <para>
+ Because any global privilege is considered a privilege for
+ all databases, any global privilege enables a user to see
+ all database names with <literal role="stmt">SHOW
+ DATABASES</literal> or by examining the
+ <literal role="is">SCHEMATA</literal> table of
+ <literal>INFORMATION_SCHEMA</literal>.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>db</literal> table scope columns determine which
+ users can access which databases from which hosts. The
+ privilege columns determine which operations are allowed. A
+ privilege granted at the database level applies to the
+ database and to all objects in the database, such as tables
+ and stored programs.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>host</literal> table is used in conjunction with
+ the <literal>db</literal> table when you want a given
+ <literal>db</literal> table row to apply to several hosts. For
+ example, if you want a user to be able to use a database from
+ several hosts in your network, leave the
+ <literal>Host</literal> value empty in the user's
+ <literal>db</literal> table row, then populate the
+ <literal>host</literal> table with a row for each of those
+ hosts. This mechanism is described more detail in
+ <xref linkend="request-access"/>.
+ </para>
+
+ <note>
+ <para>
+ The <literal>host</literal> table must be modified directly
+ with statements such as
+ <literal role="stmt">INSERT</literal>,
+ <literal role="stmt">UPDATE</literal>, and
+ <literal role="stmt">DELETE</literal>. It is not affected by
+ statements such as <literal role="stmt">GRANT</literal> and
+ <literal role="stmt">REVOKE</literal> that modify the grant
+ tables indirectly. Most MySQL installations need not use
+ this table at all.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>tables_priv</literal> and
+ <literal>columns_priv</literal> tables are similar to the
+ <literal>db</literal> table, but are more fine-grained: They
+ apply at the table and column levels rather than at the
+ database level. A privilege granted at the table level applies
+ to the table and to all its columns. A privilege granted at
+ the column level applies only to a specific column.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>procs_priv</literal> table applies to stored
+ routines. A privilege granted at the routine level applies
+ only to a single routine.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
The server uses the <literal>user</literal>,
<literal>db</literal>, and <literal>host</literal> tables in the
<literal>mysql</literal> database at both the first and second
@@ -1462,96 +1552,6 @@
</informaltable>
<para>
- Briefly, the server uses the grant tables in the following manner:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- The <literal>user</literal> table scope columns determine
- whether to reject or allow incoming connections. For allowed
- connections, any privileges granted in the
- <literal>user</literal> table indicate the user's global
- (superuser) privileges. Any privilege granted in this table
- applies to <emphasis>all</emphasis> databases on the server.
- </para>
-
- <note>
- <para>
- Because any global privilege is considered a privilege for
- all databases, any global privilege enables a user to see
- all database names with <literal role="stmt">SHOW
- DATABASES</literal> or by examining the
- <literal role="is">SCHEMATA</literal> table of
- <literal>INFORMATION_SCHEMA</literal>.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- The <literal>db</literal> table scope columns determine which
- users can access which databases from which hosts. The
- privilege columns determine which operations are allowed. A
- privilege granted at the database level applies to the
- database and to all objects in the database, such as tables
- and stored programs.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The <literal>host</literal> table is used in conjunction with
- the <literal>db</literal> table when you want a given
- <literal>db</literal> table row to apply to several hosts. For
- example, if you want a user to be able to use a database from
- several hosts in your network, leave the
- <literal>Host</literal> value empty in the user's
- <literal>db</literal> table row, then populate the
- <literal>host</literal> table with a row for each of those
- hosts. This mechanism is described more detail in
- <xref linkend="request-access"/>.
- </para>
-
- <note>
- <para>
- The <literal>host</literal> table must be modified directly
- with statements such as
- <literal role="stmt">INSERT</literal>,
- <literal role="stmt">UPDATE</literal>, and
- <literal role="stmt">DELETE</literal>. It is not affected by
- statements such as <literal role="stmt">GRANT</literal> and
- <literal role="stmt">REVOKE</literal> that modify the grant
- tables indirectly. Most MySQL installations need not use
- this table at all.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- The <literal>tables_priv</literal> and
- <literal>columns_priv</literal> tables are similar to the
- <literal>db</literal> table, but are more fine-grained: They
- apply at the table and column levels rather than at the
- database level. A privilege granted at the table level applies
- to the table and to all its columns. A privilege granted at
- the column level applies only to a specific column.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The <literal>procs_priv</literal> table applies to stored
- routines. A privilege granted at the routine level applies
- only to a single routine.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
Administrative privileges (such as
<literal role="priv">RELOAD</literal> or
<literal role="priv">SHUTDOWN</literal>) are specified only in the
@@ -1797,20 +1797,6 @@
</programlisting>
</listitem>
- <listitem>
- <para>
- With one exception, a blank <literal>Host</literal> value in
- the grant tables is the same as <literal>'%'</literal>. The
- exception is that A blank <literal>Host</literal> value in a
- <literal>db</literal> table row means that its privileges
- should be combined with those in the row in the
- <literal>host</literal> table that matches the client host
- name. The privileges are combined using an AND (intersection)
- operation, not OR (union). <xref linkend="request-access"/>,
- discusses use of the <literal>host</literal> table further.
- </para>
- </listitem>
-
</itemizedlist>
<para>
@@ -1860,8 +1846,12 @@
<literal role="func">PASSWORD()</literal> function). The encrypted
password then is used during the connection process when checking
whether the password is correct. (This is done without the
- encrypted password ever traveling over the connection.) From
- MySQL's point of view, the encrypted password is the
+ encrypted password ever traveling over the connection.) See
+ <xref linkend="user-names"/>.
+ </para>
+
+ <para>
+ From MySQL's point of view, the encrypted password is the
<emphasis>real</emphasis> password, so you should never give
anyone access to it. In particular, <emphasis>do not give
non-administrative users read access to tables in the
@@ -1869,16 +1859,6 @@
</para>
<para>
- MySQL ¤t-series; employs the stronger authentication method
- (first implemented in MySQL 4.1) that has better password
- protection during the connection process than in earlier versions.
- It is secure even if TCP/IP packets are sniffed or the
- <literal>mysql</literal> database is captured.
- <xref linkend="password-hashing"/>, discusses password encryption
- further.
- </para>
-
- <para>
The following table shows how various combinations of
<literal>Host</literal> and <literal>User</literal> values in the
<literal>user</literal> table apply to incoming connections.
@@ -2207,6 +2187,15 @@
<listitem>
<para>
+ A blank <literal>User</literal> value in the
+ <literal>db</literal> table matches the anonymous user. A
+ non-blank value matches literally; there are no wildcards in
+ user names.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
The wildcard characters <quote><literal>%</literal></quote>
and <quote><literal>_</literal></quote> can be used in the
<literal>Host</literal> and <literal>Db</literal> columns of
@@ -2248,13 +2237,6 @@
</para>
</listitem>
- <listitem>
- <para>
- A blank <literal>User</literal> value in the
- <literal>db</literal> table matches the anonymous user.
- </para>
- </listitem>
-
</itemizedlist>
<indexterm>
@@ -2513,6 +2495,10 @@
+--------------------+----+-
</programlisting>
+ </section>
+
+ <section id="privilege-changes">
+
<indexterm>
<primary>privilege</primary>
<secondary>changes</secondary>
@@ -2522,26 +2508,6 @@
<primary>changes to privileges</primary>
</indexterm>
- <indexterm>
- <primary>tables</primary>
- <secondary>grant</secondary>
- </indexterm>
-
- <indexterm>
- <primary>grant tables</primary>
- </indexterm>
-
- <para>
- Naturally, you should always test your changes to the grant tables
- (for example, by using <literal role="stmt">SHOW GRANTS</literal>)
- to make sure that your access privileges are actually set up the
- way you think they are.
- </para>
-
- </section>
-
- <section id="privilege-changes">
-
<title>When Privilege Changes Take Effect</title>
<para>
Modified: trunk/refman-6.0/programs-client-core.xml
===================================================================
--- trunk/refman-6.0/programs-client-core.xml 2009-03-25 16:42:22 UTC (rev 14366)
+++ trunk/refman-6.0/programs-client-core.xml 2009-03-25 16:42:35 UTC (rev 14367)
Changed blocks: 1, Lines Added: 7, Lines Deleted: 0; 823 bytes
@@ -1738,6 +1738,13 @@
</para>
<para>
+ The <filename>.mysql_history</filename> should be protected with
+ a restrictive access mode because sensitive information might be
+ written to it, such as the text of SQL statements that contain
+ passwords. See <xref linkend="password-security-user"/>.
+ </para>
+
+ <para>
If you do not want to maintain a history file, first remove
<filename>.mysql_history</filename> if it exists, and then use
either of the following techniques:
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r14367 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul.dubois | 25 Mar |
