From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 1582B27AD5 for ; Thu, 19 Jul 2018 03:48:49 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7x0AwT7AB9t for ; Thu, 19 Jul 2018 03:48:49 -0400 (EDT) Received: from smtp50.i.mail.ru (smtp50.i.mail.ru [94.100.177.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 99EEF27AD3 for ; Thu, 19 Jul 2018 03:48:48 -0400 (EDT) Received: by smtp50.i.mail.ru with esmtpa (envelope-from ) id 1fg3g6-00013f-G2 for tarantool-patches@freelists.org; Thu, 19 Jul 2018 10:48:46 +0300 Subject: [tarantool-patches] Re: [PATCH] Make access_check_ddl check for entity privileges. References: From: Sergey Petrenko Message-ID: Date: Thu, 19 Jul 2018 10:48:45 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0C074E4AE1EABC3D98410164" Content-Language: ru Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org This is a multi-part message in MIME format. --------------0C074E4AE1EABC3D98410164 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Sorry, forgot to send to the mailing list. -------- Перенаправленное сообщение -------- Тема: Re: [tarantool-patches] Re: [PATCH] Make access_check_ddl check for entity privileges. Дата: Thu, 19 Jul 2018 10:46:27 +0300 От: Sergey Petrenko Кому: Konstantin Osipov 18.07.2018 9:07, Konstantin Osipov пишет: > * Sergey Petrenko [18/07/12 11:55]: > >>>> - enum priv_type priv_type = new_tuple ? PRIV_C : PRIV_D; >>>> - if (old_tuple && new_tuple) >>>> - priv_type = PRIV_A; >>>> - access_check_ddl(old_space->def->name, old_space->def->uid, SC_SPACE, >>>> - priv_type, true); >>>> + enum priv_type priv_type = new_tuple ? PRIV_A : PRIV_D; >>>> + access_check_ddl(old_space->def->name, old_space->def->id, >>>> + old_space->def->uid, SC_SPACE, priv_type, true); >>> As far as I understand, you changed it because creating an index >>> is technically altering a space, not creating it. But in this case >>> dropping an index is also technically altering a space. >>> In SQL, CREATE/DROP/ALTER match SQL statements CREATE/DROP/ALTER >>> respectively. Since in NoSQL in Tarantool we don't have these >>> statements, instead, we create each index with a separate Lua >>> command, let's keep the old check: use CREATE access to space >>> in order to permit CREATING an index, ALTER - to permit update, >>> and DROP - to permit drop. >> Checking for create privilege ignores ownership, since when creating an >> object there can't be a create privilege on the object itself. > INDEX is not a separate object, it's a part of the space. > A user who has created the space should be able to > CREATE/DROP/ALTER any index in the space based on the definer > rule (the owner of the object should be able to do anything with > it). You misunderstood me, I meant the space object, since we used to check for CREATE privilege on space itself to create an index previously. Checking for ALTER on space, would allow exactly what you want with CREATE/ALTER/DROP of an index. The owner has every privilege, including ALTER, so he is able to do anything with the indices. If someone else created an index on your space, and you want to drop it, it is no problem. This is why we check for ALTER OR DROP on space in case of dropping an index. > I imagine if an index has an independent owner, one would not be > able to drop their own space if some other user created an index > on it. > > Let's try to avoid this. Oracle also has entity access. How does > it work there? Who is set as the definer of the index if user b > creates an index on space created by user a? Let's bring this up > with Peter Gulutzan, he may have an educated opinion on the > subject. What Oracle does is they have separate entities INDEX and TABLE, and in order to create an index, you need to have an INDEX privilege on a space OR you may have a CREATE ANY INDEX privilege. So, technically, non-owners can create indices in your tables, but again, if you want to drop a table, it is dropped together with all the indices no matter who their owner is. (The same thing we may achieve with privilege checks that I and Georgy propose). > > We also have an option of separating INDEX and SPACE as entities, > and introducing INDEX entity. But then again a user who created a > space should be able to create/drop/alter any index in that space > - the opposite seems counter-intuitive. IMO it would unnecessarily complicate access control, cos we would need to grant all the needed privileges on an index to space owner, and we also would have to make it so that theese privileges cannot be revoked. OR we can set space owner as the definer of any index created on that space, but again, this seems strange. If you are a non-owner of the space, you create an index and immediately lose control over it. We may also consult with Peter Gulutzan. Do you want me to write him? --------------0C074E4AE1EABC3D98410164 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Sorry, forgot to send to the mailing list.

-------- Перенаправленное сообщение --------
Тема: Re: [tarantool-patches] Re: [PATCH] Make access_check_ddl check for entity privileges.
Дата: Thu, 19 Jul 2018 10:46:27 +0300
От: Sergey Petrenko <sergepetrenko@tarantool.org>
Кому: Konstantin Osipov <kostja@tarantool.org> 

18.07.2018 9:07, Konstantin Osipov пишет:
> * Sergey Petrenko <sergepetrenko@tarantool.org> [18/07/12 11:55]:
>
>>>> -	enum priv_type priv_type = new_tuple ? PRIV_C : PRIV_D;
>>>> -	if (old_tuple && new_tuple)
>>>> -		priv_type = PRIV_A;
>>>> -	access_check_ddl(old_space->def->name, old_space->def->uid, SC_SPACE,
>>>> -			 priv_type, true);
>>>> +	enum priv_type priv_type = new_tuple ? PRIV_A : PRIV_D;
>>>> +	access_check_ddl(old_space->def->name, old_space->def->id,
>>>> +			 old_space->def->uid, SC_SPACE, priv_type, true);
>>> As far as I understand, you changed it because creating an index
>>> is technically altering a space, not creating it. But in this case
>>> dropping an index is also technically altering a space.
>>> In SQL, CREATE/DROP/ALTER match SQL statements CREATE/DROP/ALTER
>>> respectively. Since in NoSQL in Tarantool we don't have these
>>> statements, instead, we create each index with a separate Lua
>>> command, let's keep the old check: use CREATE access to space
>>> in order to permit CREATING an index, ALTER - to permit update,
>>> and DROP - to permit drop.
>> Checking for create privilege ignores ownership, since when creating an
>> object there can't be a create privilege on the object itself.
> INDEX is not a separate object, it's a part of the space.
> A user who has created the space should be able to
> CREATE/DROP/ALTER any index in the space based on the definer
> rule (the owner of the object should be able to do anything with
> it).
You misunderstood me, I meant the space object, since we used to
check for CREATE privilege on space itself to create an index previously.
Checking for ALTER on space, would allow exactly what you want with
CREATE/ALTER/DROP of an index. The owner has every privilege, including
ALTER, so he is able to do anything with the indices.
If someone else created an index on your space, and you want to drop it,
it is no problem. This is why we check for ALTER OR DROP on space in case
of dropping an index.
> I imagine if an index has an independent owner, one would not be
> able to drop their own space if some other user created an index
> on it.
>
> Let's try to avoid this. Oracle also has entity access. How does
> it work there? Who is set as the definer of the index if user b
> creates an index on space created by user a? Let's bring this up
> with Peter Gulutzan, he may have an educated opinion on the
> subject.
What Oracle does is they have separate entities INDEX and TABLE,
and in order to create an index, you need to have an INDEX privilege
on a space OR you may have a CREATE ANY INDEX privilege.
So, technically, non-owners can create indices in your
tables, but again, if you want to drop a table, it is dropped together
with all the indices no matter who their owner is. (The same thing we
may achieve with privilege checks that I and Georgy propose).
>
> We also have an option of separating INDEX and SPACE as entities,
> and introducing INDEX entity. But then again a user who created a
> space should be able to create/drop/alter any index in that space
> - the opposite seems counter-intuitive.
IMO it would unnecessarily complicate access control, cos we would
need to grant all the needed privileges on an index to space owner,
and we also would have to make it so that theese privileges cannot be 
revoked.
OR we can set space owner as the definer of any index created on that space,
but again, this seems strange. If you are a non-owner of the space,
you create an index and immediately lose control over it.

We may also consult with Peter Gulutzan. Do you want me to write him?
--------------0C074E4AE1EABC3D98410164--