|
|
|
|
| |
After executing those statements, the test database directory also will contain files named x.frm, x.MYD, and x.MYI. In other words, the test database will contain a table x that is a stolen duplicate of the table in the other_db database.
To avoid having someone attack your users' tables in the same way, set the permissions on your data directory contents according to the instructions given earlier in this chapter in the "Securing Your MySQL Installation" section. As an additional measure, you can also use the --skip-show-database option when you start the server to limit users from using SHOW DATABASES and from using SHOW TABLES for databases to which they have no access. This helps prevent users from finding out about databases and tables they shouldn't be accessing.
The dangers of the FILE privilege are amplified if you run the MySQL server as root. That's inadvisable in the first place, and is particularly so when combined with FILE. Because root can create files anywhere in the file system, a user with the FILE privilege can do so as well, even a user who has connected from a remote host. The server won't create a file that already exists, but it's sometimes possible to create new files that will alter the operation of the server host or compromise its security. For example, if any of the /etc/resolv.conf, /etc/hosts.equiv, /etc/hosts.lpd, or /etc/sudoers files do not exist, a user who can use the MySQL server to create them can drastically change the way your server host behaves. To avoid these problems, don't run mysqld as root. (See the "Running the Server Using an Unprivileged Login Account" section in Chapter 11.)
The PROCESS privilege should be granted only to trusted MySQL accounts. With PROCESS, a user can use SHOW PROCESSLIST to see the text of queries being executed by the server. This allows a user to snoop on other users and possibly see information that should remain private.
Don't give people the RELOAD privilege who don't need it. RELOAD allows a user to issue FLUSH and RESET statements, which can be abused in several ways:
If you have configured the server to perform update or binary update logging using a numbered sequence of files, each FLUSH LOGS statement creates a new update or binary update log file. A user with the RELOAD privilege who performs many log flushing operations can cause the server to create large numbers of files.
A user with the RELOAD privilege can defeat the resource management mechanism by reloading the grant tables with FLUSH PRIVILEGES or with FLUSH USER_RESOURCES. Both statements reset all resource management counters to zero.
FLUSH TABLES can be used repeatedly to cause the server to flush its open-table cache, which degrades performance by preventing the server from taking advantage of the cache. RESET QUERY CACHE has the same effect on performance by negating the benefits of the query cache.
RESET MASTER LOGS causes a replication master server to delete all of its binary update logs whether or not they are still in use, which removes the information necessary to maintain replication integrity.
The ALTER privilege can be used in ways you may not intend. Suppose you want user1 to be able to access table1 but not table2. A user with the ALTER privilege may be able to subvert your intent by using ALTER TABLE to rename table2 to table1.
Setting Up MySQL Accounts Without GRANT Statements
If you have a version of MySQL older than 3.22.11, you can't use the GRANT (or REVOKE) statements to manage MySQL accounts and access privileges. However, you can modify the contents of the grant tables directly using statements like INSERT. It's easier to do that if you understand how the GRANT statement modifies the grant tables because you'll know what kind of INSERT statements correspond to various GRANT statements.
|
|
|
|
|
|
| Link Partners: Asia florist, Flowers to India, Hong kong flowers, Site submit, Cheap web hosting, China florist, Japan florist |
|
