Hello, Karen!
2008/5/20 Karen Abgarian <abvk@stripped>:
>
> On May 20, 2008, at 2:18 AM, Sergei Golubchik wrote:
>
>> Hi!
>>
>> On May 20, Sergey Kudriavtsev wrote:
>>>
>>> Hello, everyone.
>>>
>>> So, I'm going to implement some basic role functionality in another two
>>> weeks.
>>>
>>> Exactly, I'm planning to do the following:
>>>
>>> 1. Add new necessary fields to mysql.user table:
>>>
>>> Default_role char(16) binary;
>>> Comment varchar(50);
>>> Create_role_priv enum('N','Y') character set utf8 NOT NULL default 'N';
>>> Drop_role_priv enum('N','Y') character set utf8 NOT NULL default 'N'.
>>>
>>> To distinguish roles from users I propose to use "Host" field of
>>> mysql.user table - If this field is empty then we should consider the
>>> specified record to be a role.
>>> Now empty field is equivalent to '%'. I will change the behaviour of
>>> parser to always fail host identity check when the checked field has
>>> empty value. I will also change mysql_fix_privilege_tables script to
>>> replace all existing empty "Host" field values with '%'.
>>
>> This is fine, but what are you going to do with mysql.host table ? In
>> there empty host is not equivalent to '%' :(
>
> i apologize for breaking in, but if you are already extending the
> mysql.user,
> why don't you just add another flag field for this instead of reusing a
> column?
> IMHO, this creates confusion. A related question is, the similarity of
> users and
> roles is an internal implementation feature, the users think of users and
> roles
> as separate entities.
OK, as I see from feedback this is the most preferable way :)
> Perhaps it makes sense to follow a typical Oracle
> approach
> and create a common (possibly hidden) table with the user/role information +
> mysql.user and mysql.role as views on that.
>
I'm not sure whether MySQL has something like that. And if not then I wonder
if it's really necessary to implement such `view` approach?
> The necessity of the create/drop_role_priv is unclear to me, I would say it
> belongs
> to the grants table.
>
create/drop_role_priv will hold new privileges of using new CREATE ROLE
and DROP ROLE statements. Those privileges are global-level and they
must be stored in mysql.user table in the same way CREATE USER/DROP USER
privileges are stored in corresponding columns of this table.
> Sorry if this is out of bounds.
>
>
> Tx/Rgs
> Karen
>
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:
> http://lists.mysql.com/internals?unsub=1
>
>
--
Best regards,
Sergey Kudriavtsev
