[Maria-developers] MDEV-7628 Row-based replication of old DECIMAL to new DECIMAL
Hi Sergei, Kristian, all, Thanks to everyone who participated in the discussion on this topic. I tried to collect all ideas into a JIRA task: https://mariadb.atlassian.net/browse/MDEV-7628 Please have a look. Thanks. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] PLEASE REVIEW: (MDEV-7574) Security definer views don't work with CONNECT ODBC tables
Hi Sergei,
On 02/19/2015 07:12 PM, Sergei Golubchik wrote:
Hi, Alexander!
On Feb 17, Alexander Barkov wrote:
From what I understood, FILE_ACL is written (among the other
privileges) into thd->security_ctx.privilege in
TABLE_LIST::prepare_security(). In case of a DEFINER view,
thd->security_ctx.privilege is filled exactly with the definer
privileges, and to the invoker privileges otherwise.
So inside ha_connect::check_privileges() the fact that there is
FILE_ACL in thd->security_ctx.privilege means that
TABLE_LIST::prepare_security() was previously called and FILE_ACL is
set to DEFINER or INVOKER, according to the view definition. This is
exactly what we need.
Agree, looks good so far :)
I'm not sure about the opposite: if there is no FILE_ACL in
thd->security_ctx.privilege, what does it mean? Does it mean that
there is no FILE_ACL for the effective user? Or can it also mean that
TABLE_LIST::prepare_security() was not called?
As far as I can see, TABLE_LIST::prepare_security() is always called for
a view that was successfully opened. That is, no FILE_ACL bit means that
there is no FILE privilege.
=== modified file 'storage/connect/ha_connect.cc'
--- storage/connect/ha_connect.cc 2015-01-20 00:21:56 +
+++ storage/connect/ha_connect.cc 2015-02-17 13:46:34 +
@@ -3865,6 +3865,8 @@ bool ha_connect::check_privileges(THD *t
case TAB_MAC:
case TAB_WMI:
case TAB_OEM:
+ if (table && (table->grant.privilege & FILE_ACL))
+return false;
return check_access(thd, FILE_ACL, db, NULL, NULL, 0, 0);
I don't like that you use both approaches to check the privileges. This
just looks wrong. It should rather be
* if it's called from ::external_lock() - use table->grant.privilege.
* otherwise (::create() or ::delete_or_rename_table()) - don't use
table->grant.privilege, only use check_access().
Something like
if (called_from_external_lock)
return table->grant.privilege & FILE_ACL; // respect view's definer
else
return check_access(thd, FILE_ACL, db, NULL, NULL, 0, 0);
Thanks for the suggestion!
Please find a new version attached. It now uses
thd_sql_command() and lock_type to decide whether
to use table->grant.privilege or check_access().
There is only one problem with that. In case of embedded server
table->grant.privilege is always 0, because the embedded version
of check_table_access() is just an empty function.
This change in sql/handler.cc, in handler::ha_external_lock() helps:
+#ifdef NO_EMBEDDED_ACCESS_CHECKS
+ table->grant.privilege= ~NO_ACCESS;
+#endif
With this change "mtr --embedded" passes all tests,
including those I added in this patch.
Possibly, a there is a better way to do this.
Please suggest.
Thanks.
Regards,
Sergei
=== modified file 'sql/handler.cc'
--- sql/handler.cc 2015-01-21 11:03:02 +
+++ sql/handler.cc 2015-02-24 11:47:05 +
@@ -5873,6 +5873,9 @@ int handler::ha_external_lock(THD *thd,
ha_statistic_increment(&SSV::ha_external_lock_count);
+#ifdef NO_EMBEDDED_ACCESS_CHECKS
+ table->grant.privilege= ~NO_ACCESS;
+#endif
/*
We cache the table flags if the locking succeeded. Otherwise, we
keep them as they were when they were fetched in ha_open().
=== modified file 'storage/connect/ha_connect.cc'
--- storage/connect/ha_connect.cc 2015-02-11 20:39:41 +
+++ storage/connect/ha_connect.cc 2015-02-24 12:03:25 +
@@ -3922,7 +3922,21 @@ int ha_connect::delete_all_rows()
} // end of delete_all_rows
-bool ha_connect::check_privileges(THD *thd, PTOS options, char *dbn)
+/**
+ Check privileges.
+ @param THD - Current thread
+ @param options - Connect table options
+ @param dbn - database name
+ @param using_table_privilege - whether check table->grant.privilege,
+ or execute check_access(FILE_ACL).
+
+ Using table->grant.privilege is important in cases when we need to take into
+ account privileges of the VIEW definer when accessing to a view created with
+"CREATE VIEW v1 SQL SECURITY DEFINER".
+ See ha_connect::check_privileges_external_lock() for details.
+*/
+bool ha_connect::check_privileges(THD *thd, PTOS options,
+ char *dbn, bool using_table_privilege)
{
const char *db= (dbn && *dbn) ? dbn : NULL;
TABTYPE type=GetRealType(options);
@@ -3978,7 +3992,25 @@ bool ha_connect::check_privileges(THD *t
case TAB_MAC:
case TAB_WMI:
case TAB_OEM:
- return check_access(thd, FILE_ACL, db, NULL, NULL, 0, 0);
+ if (using_table_privilege)
+ {
+// Called from ::external_lock(), respect VIEW's definer
+if (table->grant.privilege & FILE_ACL)
+ return false;
+else
+{
+ my_error(ER_ACCESS_DENIED_ERROR, MYF(0),
+ thd->security_ctx->priv_user,
+ thd->security_ctx->priv_host,
+ (thd->password ? ER(ER
Re: [Maria-developers] Contributing in Support for GTID in mysqlbinlog for GSoC'15
Rohit Kashyap writes: > I am having a doubt, > GTID assignss unique identifier to every transaction. > And gtid_mode variable is not dynamic.Should the constraint of > matching the master and replica be dropped to implement this. I am sorry, I do not understand what you are asking? Agree, GTIDs are unique for every transaction. But I do not understand about gtid_mode. There is no ariable "gtid_mode" in MariaDB. Do you mean gtid_strict_mode? But gtid_strict_mode is dynamic. And what do you mean with "contraint of matching the master and replica"? I do not see why any constraints on replicas would be needed with respect to MDEV-4989. - Kristian. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Contributing in Support for GTID in mysqlbinlog for GSoC'15
Hi Kristian, I am having a doubt, GTID assignss unique identifier to every transaction. And gtid_mode variable is not dynamic.Should the constraint of matching the master and replica be dropped to implement this. On 2/23/15, Kristian Nielsen wrote: > Rohit Kashyap writes: > >> I am Rohit Kashyap, I am currently working on MDEV-7569 >> and recently came over to your post on Support for GTID in mysqlbinlog >> [MDEV-4989] >> I would like to ask you for guidance and leads on this so that I can >> take it up as my GSoC'15 Project under MariaDB. > > So I took a quick look at what mysqlbinlog currently supports, and how it > could be extended to GTID. Looks like it's actually pretty clear: > > - The --start-position and --stop-position options should be able to take >GTID positions; or maybe there should be new --start-gtid and > --stop-gtid >options. Like "--start-gtid=0-1-100,1-2-200,2-1-1000". > > - A GTID position means the point just _after_ that GTID. So starting from >GTID 0-1-100 and stopping at GTID 0-1-200, the first GTID output will >probably be 0-1-101 and the last one 0-1-200. Note that if some domain > is >not specified in the position, it means to start from the begining, >respectively stop immediately in that domain. > > - Starting and stopping GTID should work both with local files, and with >--read-from-remote-server. For the latter, there are a couple of extra >things that need doing in the master-slave protocol, see >get_master_version_and_clock() in sql/slave.cc. > > - At the end of the dump, put these statements as discussed in the bug: >SET session.server_id = @@global.server_id, >session.gtid_domain_id=@@global.gtid_domain_id; > > Probably some more things will come up during the work, but this looks like > a > reasonable start. > > I would recommend to start by reading the GTID documentation, and > experimenting with all the relevant features described there, to > familiarise > yourself with it. The main thing is to understand the concept of GTID > position > and binlog order, and the relation to replication domains: > > https://mariadb.com/kb/en/mariadb/global-transaction-id/ > > And similarly, familiarise yourself with mysqlbinlog and how it would make > sense for it to be extended to support GTID. > > Then make a detailed proposal for how the user-visible interface of > mysqlbinlog should be extended, and send it to the list for comments. > > The next step will be to understand the concept of binlog state > (@@gtid_binlog_state), and how it is used to deal correctly with > out-of-order > GTID sequence numbers in binlogs. This is mostly an internal implementation > detail, but necessary to be able to correctly identify starting and > stopping > GTID positions in all cases. > > Hope this helps, > > - Kristian. > -- Kind Regards, Rohit ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] passwordless mariadb root login with auht_socket in Debian
Another dirty way to do so by avoiding the use of a PROCEDURE is to use
a prepared statement :
SET @inst_plug=IF((SELECT 1 FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME='unix_socket' AND PLUGIN_STATUS='ACTIVE' AND
PLUGIN_TYPE='AUTHENTICATION' AND PLUGIN_LIBRARY LIKE
CONCAT('auth_socket','%'))=1, 'SELECT 1 LIMIT 0', "INSTALL PLUGIN
unix_socket SONAME 'auth_socket'");
PREPARE inst_plug FROM @inst_plug;
EXECUTE inst_plug;
It will install the plugin if not present and wont return anything (and
no error) on the other case.
As for the idea to do it the simplest way (simply execute the INSTALL
PLUGIN statement) and skip the exit on error as done for the
"$password_column_fix_query" execution just few lines before ("set +e").
That way, the INSTALL PLUGIN statement could be added directly to the
"$password_column_fix_query" execution rather than re-starting once more
mysqld without even checking its exit status.
ps: as a side note, the content of the replace_query variable set on
line 160 should be directly put on the line 192 as its only called once.
Le 24/02/2015 11:49, Daniel Black a écrit :
- Original Message -
Thanks for your help!
How should this then be re-written correctly?
Thinking strip away the procedures and work directly with a query of the
information schema.
perhaps even just call: set sql_log_bin=0; install plugin "unix_socket"
and ignore the error if it exists..
SET sql_log_bin=0; USE mysql; DELIMITER //; CREATE PROCEDURE
debian_plugin_install(IN plugin_name CHAR(50), IN soname CHAR(50))
BEGIN DECLARE CONTINUE HANDLER FOR NOT FOUND EXECUTE
inst_plug; set @plugin_name=plugin_name; set @soname=soname ;set
@install_plugin=CONCAT(\"INSTALL PLUGIN \",@plugin_name,\" SONAME '\",
@soname, \"'\");PREPARE inst_plug FROM @install_plugin ;
select PLUGIN_NAME INTO @a from information_schema.plugins where
PLUGIN_NAME=@plugin_name AND PLUGIN_STATUS='ACTIVE' AND
PLUGIN_TYPE='AUTHENTICATION' AND PLUGIN_LIBRARY LIKE
concat(@soname,'%'
); DEALLOCATE PREPARE inst_plug; END// CALL
debian_plugin_install('unix_socket', 'auth_socket') // DROP PROCEDURE
debian_plugin_install//
https://github.com/ottok/mariadb-10.0/blob/master/debian/mariadb-server-10.0.postinst#L179
Pull requests appreciated :)
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] passwordless mariadb root login with auht_socket in Debian
- Original Message -
> Thanks for your help!
>
> How should this then be re-written correctly?
Thinking strip away the procedures and work directly with a query of the
information schema.
perhaps even just call: set sql_log_bin=0; install plugin "unix_socket"
and ignore the error if it exists..
> SET sql_log_bin=0; USE mysql; DELIMITER //; CREATE PROCEDURE
> debian_plugin_install(IN plugin_name CHAR(50), IN soname CHAR(50))
> BEGIN DECLARE CONTINUE HANDLER FOR NOT FOUND EXECUTE
> inst_plug; set @plugin_name=plugin_name; set @soname=soname ;set
> @install_plugin=CONCAT(\"INSTALL PLUGIN \",@plugin_name,\" SONAME '\",
> @soname, \"'\");PREPARE inst_plug FROM @install_plugin ;
> select PLUGIN_NAME INTO @a from information_schema.plugins where
> PLUGIN_NAME=@plugin_name AND PLUGIN_STATUS='ACTIVE' AND
> PLUGIN_TYPE='AUTHENTICATION' AND PLUGIN_LIBRARY LIKE
> concat(@soname,'%'
> ); DEALLOCATE PREPARE inst_plug; END// CALL
> debian_plugin_install('unix_socket', 'auth_socket') // DROP PROCEDURE
> debian_plugin_install//
>
> https://github.com/ottok/mariadb-10.0/blob/master/debian/mariadb-server-10.0.postinst#L179
>
> Pull requests appreciated :)
>
--
--
Daniel Black, Engineer @ Open Query (http://openquery.com.au)
Remote expertise & maintenance for MySQL/MariaDB server environments.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] passwordless mariadb root login with auht_socket in Debian
The procedure is used here as it only executes "INSTALL PLUGIN
unix_socket SONAME 'auth_socket';" if the plugin is not actually loaded
(would output an error if it was the case).
Another small issue of the actual approach is that it requires another
mysqld execution just for this task which takes some times and is
especially problematic when doing a package upgrade.
Le 24/02/2015 10:06, Otto Kekäläinen a écrit :
Thanks for your help!
How should this then be re-written correctly?
SET sql_log_bin=0; USE mysql; DELIMITER //; CREATE PROCEDURE
debian_plugin_install(IN plugin_name CHAR(50), IN soname CHAR(50))
BEGIN DECLARE CONTINUE HANDLER FOR NOT FOUND EXECUTE
inst_plug; set @plugin_name=plugin_name; set @soname=soname ;set
@install_plugin=CONCAT(\"INSTALL PLUGIN \",@plugin_name,\" SONAME '\",
@soname, \"'\");PREPARE inst_plug FROM @install_plugin ;
select PLUGIN_NAME INTO @a from information_schema.plugins where
PLUGIN_NAME=@plugin_name AND PLUGIN_STATUS='ACTIVE' AND
PLUGIN_TYPE='AUTHENTICATION' AND PLUGIN_LIBRARY LIKE
concat(@soname,'%'
); DEALLOCATE PREPARE inst_plug; END// CALL
debian_plugin_install('unix_socket', 'auth_socket') // DROP PROCEDURE
debian_plugin_install//
https://github.com/ottok/mariadb-10.0/blob/master/debian/mariadb-server-10.0.postinst#L179
Pull requests appreciated :)
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] passwordless mariadb root login with auht_socket in Debian
Thanks for your help!
How should this then be re-written correctly?
SET sql_log_bin=0; USE mysql; DELIMITER //; CREATE PROCEDURE
debian_plugin_install(IN plugin_name CHAR(50), IN soname CHAR(50))
BEGIN DECLARE CONTINUE HANDLER FOR NOT FOUND EXECUTE
inst_plug; set @plugin_name=plugin_name; set @soname=soname ;set
@install_plugin=CONCAT(\"INSTALL PLUGIN \",@plugin_name,\" SONAME '\",
@soname, \"'\");PREPARE inst_plug FROM @install_plugin ;
select PLUGIN_NAME INTO @a from information_schema.plugins where
PLUGIN_NAME=@plugin_name AND PLUGIN_STATUS='ACTIVE' AND
PLUGIN_TYPE='AUTHENTICATION' AND PLUGIN_LIBRARY LIKE
concat(@soname,'%'
); DEALLOCATE PREPARE inst_plug; END// CALL
debian_plugin_install('unix_socket', 'auth_socket') // DROP PROCEDURE
debian_plugin_install//
https://github.com/ottok/mariadb-10.0/blob/master/debian/mariadb-server-10.0.postinst#L179
Pull requests appreciated :)
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] passwordless mariadb root login with auht_socket in Debian
DELIMITERs are (should be) definitely handled in the client. The server does not know about it. It is also not listed here http://dev.mysql.com/doc/refman/5.6/en/sql-syntax.html for same reason. -- Peter On Tue, Feb 24, 2015 at 3:05 AM, Daniel Black wrote: > > > - Original Message - > > Manually executing the command result in this error : > > ERROR: 1064 You have an error in your SQL syntax; check the > > manual that corresponds to your MariaDB server version for the right > > syntax to use near 'USE mysql;DELIMITER //; CREATE PROCEDURE > > debian_plugin_install(IN plugin_name C' at line 1 > > 150223 22:44:06 [ERROR] Aborting > > > > By adding \n between each of these statements we can see that the > > statement causing the syntax error is "DELIMITER //;", it seems that > > DELIMITER is only used by mysql client and the that mysqld doesnt > > recognize it as an internal command. > > thank you > > > -- > -- > Daniel Black, Engineer @ Open Query (http://openquery.com.au) > Remote expertise & maintenance for MySQL/MariaDB server environments. > > ___ > Mailing list: https://launchpad.net/~maria-developers > Post to : maria-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~maria-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
