Maybe it is because you can manually create temporary tables in Stored
Procedures.
Creating tables using 'create_priv' allows other users to view your table if
the other users have 'select_priv' for that same table.
Creating tables using 'create_tmp_table_priv' allows only the calling user
to view that table within the current MySQL session. You can drop temp tables
you make within a connection. Once a connection terminates, all temp tables
are dropped. If a person forgets to drop temp tables and stays within a
connection
for hours or even days, memory resources can be overloaded a lot of temp tables.
Furthermore, loading temp tables with a GB of data is bad practice but is
possible
under such circumstances.
Would you want every user who has 'Create_routine_priv' and 'Alter_Routine_Priv'
to go willy-nilly on temp tables? Other than root, DBAs and other superusers
who know
what they are doing, that invites memory problems on the part of Stored
Procedure developers.
If a Server has been hacked using a mysql user that is not root, you want to be
sure
the mysql user being used in a hack does not create denial of service problems
by
ballooning temp tables here and there. Why worry about this scenario ???
Remember : TEMPORARY TABLES ARE NOT VISIBLE !!!!
EXAMPLE
-------
create temporary table test.namelist ( id int not null auto_increment, name
varchar(100), primary key (id) );
insert into test.namelist (name) values ('JOHN'),('GROVER'),('JEFF'),('MIKE');
THEY DO NOT APPEAR when you run the following three ways:
1) use test
show tables;
2) select table_name from information_schema.tables where table_schema='test';
3) select table_name from information_schema.tables where
table_name='namelist';
Yet, you can select from, delete from, insert into,
and update temporary tables because they do exist.
mysql> select * from test.namelist;
+----+--------+
| id | name |
+----+--------+
| 1 | JOHN |
| 2 | GROVER |
| 3 | JEFF |
| 4 | MIKE |
+----+--------+
4 rows in set (0.00 sec)
Imagine the havoc a person could wreak maliciously or accidently with temporary
tables.
Unless you know that exact name of the table, you cannot drop it. What makes
this worse
is that you have to be within the connection that created the temporary table
in the first
place to even manipulate it or delete it.
Of course, killing a connection drops all temporary tables
created in the session of the MySQL connection. Shutting
down MySQL drops all temporary tables from the server.
----- Original Message -----
From: Marten Lehmann <[EMAIL PROTECTED]>
To: mysql@lists.mysql.com
Sent: Tuesday, November 14, 2006 10:49:57 AM GMT-0500 US/Eastern
Subject: question on create_tmp_table_priv
Hello,
if there are not any security impacts, why does the
Create_tmp_table-privilege exist separately to the
create_table-privilege? Or if it has security impacts (maybe
automatically granting other rights), which ones?
The mysql documentation doesn't tell much about this.
Regards
Marten
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
