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 83B6421A13 for ; Wed, 18 Jul 2018 12:52:51 -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 pTeCvOTrHhJH for ; Wed, 18 Jul 2018 12:52:51 -0400 (EDT) Received: from smtp61.i.mail.ru (smtp61.i.mail.ru [217.69.128.41]) (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 3DB6F2187D for ; Wed, 18 Jul 2018 12:52:51 -0400 (EDT) Date: Wed, 18 Jul 2018 09:07:48 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH] Make access_check_ddl check for entity privileges. Message-ID: <20180718060747.GA11097@chai> References: <20180711164036.33604-1-sergepetrenko@tarantool.org> <20180711183358.GA31667@chai> <5cece723-7439-563c-ea02-18014aa1294c@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5cece723-7439-563c-ea02-18014aa1294c@tarantool.org> 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: Sergey Petrenko Cc: tarantool-patches@freelists.org * 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). 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. 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. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov