An error occurred fetching the project authors.
- 02 Feb, 2009 1 commit
-
-
Matthias Leich authored
- If missing: add "disconnect <session>" - If physical disconnect of non "default" sessions is not finished at test end: add routine which waits till this happened + additional improvements like - remove superfluous files created by the test - replace error numbers by error names - remove trailing spaces, replace tabs by spaces - unify writing of bugs within comments - correct comments - minor changes of formatting Modifications according to the code review are included. Fixed tests: grant2 grant3 lock_tables_lost_commit mysqldump openssl_1 outfile
-
- 27 Sep, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
When expanding a * in a USING/NATURAL join the check for table access for both tables in the join was done using the grant information of the first one. Fixed by getting the grant information for the current table while iterating through the columns of the join.
-
- 08 Jun, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
In case of database level grant the database name may be a pattern, in case of table|column level grant the database name can not be a pattern. We use 'dont_check_global_grants' as a flag to determine if it's database level grant command (see SQLCOM_GRANT case, mysql_execute_command() function) and set db_is_pattern according to 'dont_check_global_grants' value.
-
- 23 May, 2007 1 commit
-
-
dlenev@mockturtle.local authored
Bug #23667 "CREATE TABLE LIKE is not isolated from alteration by other connections" Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open" As well as: Bug #25578 "CREATE TABLE LIKE does not require any privileges on source table". The first and the second bugs resulted in various errors and wrong binary log order when one tried to execute concurrently CREATE TABLE LIKE statement and DDL statements on source table or DML/DDL statements on its target table. The problem was caused by incomplete protection/table-locking against concurrent statements implemented in mysql_create_like_table() routine. We solve it by simply implementing such protection in proper way (see comment for sql_table.cc for details). The third bug allowed user who didn't have any privileges on table create its copy and therefore circumvent privilege check for SHOW CREATE TABLE. This patch solves this problem by adding privilege check, which was missing. Finally it also removes some duplicated code from mysql_create_like_table(). Note that, altough tests covering concurrency-related aspects of CREATE TABLE LIKE behaviour will only be introduced in 5.1, they were run manually for this patch as well.
-
- 26 Feb, 2007 1 commit
-
-
msvensson@pilot.blaudden authored
- Use mysql_system_tables.sql to create MySQL system tables in all places where we create them(mysql_install_db, mysql-test-run-pl and mysql_fix_privilege_tables.sql)
-
- 28 Jun, 2006 1 commit
-
-
iggy@mysql.com authored
-
- 18 Apr, 2006 2 commits
-
-
msvensson@neptunus.(none) authored
-
msvensson@shellback.(none) authored
- Strip surrounding ''s from username when a new user connects. There is no user 'a@', it should be a@
-
- 02 Mar, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
database - Fix test case for systems with "lowercase names"
-
- 27 Feb, 2006 1 commit
-
-
msvensson@devsrv-b.mysql.com authored
- Use binary charset in acl_cache, to make searches case sensitive - Add testcase
-
- 26 Jan, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
Cleanup the sideeffects from most of the testcases with sideeffects.
-
- 28 Dec, 2005 2 commits
-
-
msvensson@neptunus.(none) authored
- Update patch for 5.0 - Added common function to be called when 'acl_users' has been modified
-
msvensson@neptunus.(none) authored
- DROP USER command didn't reload the acl_check_hosts cache causing subsequent connect's via TCP to fail randomly. - 4.1 version
-
- 01 Sep, 2005 1 commit
-
-
dlenev@mysql.com authored
multi-threaded environment". To avoid deadlocks between several simultaneously run account management commands (particularly between FLUSH PRIVILEGES/SET PASSWORD and GRANT commands) we should always take table and internal locks during their execution in the same order. In other words we should first open and lock privilege tables and only then obtain acl_cache::lock/LOCK_grant locks.
-
- 22 Aug, 2005 1 commit
-
-
jimw@mysql.com authored
user to update with 'SET PASSWORD = ...'. (Bug #12302)
-
- 28 Jul, 2005 1 commit
-
-
monty@mysql.com authored
-
- 29 Mar, 2005 2 commits
-
-
jimw@mysql.com authored
mysql-test-run to the tests themselves.
-
serg@serg.mylan authored
-
- 27 Mar, 2005 1 commit
-
-
serg@serg.mylan authored
-
- 23 Mar, 2005 1 commit
-
-
serg@serg.mylan authored
report correct errror in MODE_NO_AUTO_CREATE_USER cleanup after merge fixes
-
- 22 Mar, 2005 2 commits
-
-
mysqldev@mysql.com authored
New privilege CREATE USER (CREATE_USER_ACL, Create_user_priv) added grant2.test: new tests (mostly backported from jani's patch) system_mysql_db.result, sp.result, grant2.result, grant.result: results updated
-
jani@ua141d10.elisa.omakaista.fi authored
- Changed error message in sql_acl.cc - Added some more tests for GRANT.
-
- 18 Mar, 2005 1 commit
-
-
Added new logic to ACL system: 1) If GRANT OPTION (not mysql db): Ok to update existing user, but not password. Not allowed to make a new user. 2) If UPDATE_ACL to mysql DB: Ok to update current user, but not make a new one. 3) If INSERT_ACL to mysql DB: Ok to add a new user, but not modify existing. 4) If GRANT OPTION to mysql DB: All modifications OK.
-
- 17 Mar, 2005 1 commit
-
-
First one is related to Bug#7905. One should not be allowed to create new user with password without UPDATE privilege to MySQL database. Furthermore, executing the same GRANT statement twice would actually crash the server and corrupt privilege database. Other bug was that one could update a column, using the existing value as basis to calculate the new value (e.g. UPDATE t1 SET a=a+1) without SELECT privilege to the field (a in the above example) Fixed tests grant.pl and grant2, which were wrong.
-
- 04 Mar, 2005 1 commit
-
-
jimw@mysql.com authored
-
- 03 Mar, 2005 1 commit
-
-
jimw@mysql.com authored
hostnames to not be matched correctly. (Bug #3309)
-
- 31 Dec, 2004 2 commits
-
-
serg@sergbook.mysql.com authored
-
serg@sergbook.mysql.com authored
-
- 23 Dec, 2004 1 commit
-
-
acurtis@pcgem.rdg.cyberkinetica.com authored
Implement fine-grained control over access to stored procedures Privileges are cached (same way as existing table/column privs)
-
- 27 Nov, 2004 1 commit
-
-
serg@serg.mylan authored
-
- 26 Nov, 2004 1 commit
-
-
ingo@mysql.com authored
(was from WL#2050 - CREATE USER and DROP USER and RENAME USER)
-
- 25 Nov, 2004 1 commit
-
-
ingo@mysql.com authored
Added new commands CREATE USER and RENAME USER. Changed behaviour of DROP USER. Changed an error messages for the new commands.
-
- 02 Nov, 2004 1 commit
-
-
gluh@gluh.mysql.r18.ru authored
-
- 20 Oct, 2004 1 commit
-
-
dlenev@brandersnatch.localdomain authored
he has SELECT and INSERT privileges for table with primary key" Now we set lex->duplicates= DUP_UPDATE right in parser if INSERT has ON DUPLICATE KEY UPDATE clause, this simplifies insert_precheck() function (this also fixes a bug) and some other code.
-
- 08 Jul, 2004 1 commit
-
-
bar@mysql.com authored
-
- 05 Apr, 2004 1 commit
-
-
gluh@gluh.mysql.r18.ru authored
'SHOW GRANTS' syntax is added 'SHOW GRANTS FOR CURRENT_USER' syntax is added 'SHOW GRANTS FOR CURRENT_USER()' syntax is added CURRENT_USER without parens in expressions(SELECT CURRENT_USER;)
-
- 28 Jul, 2003 1 commit
-
-
serg@serg.mylan authored
-
- 22 Jul, 2003 2 commits
-
-
serg@serg.mylan authored
-
serg@serg.mylan authored
-