Re: Doc patch, further describe and-mask nature of the permission system

Поиск
Список
Период
Сортировка
От Karl O. Pinc
Тема Re: Doc patch, further describe and-mask nature of the permission system
Дата
Msg-id 1355694017.14922.0@mofo
обсуждение исходный текст
Ответ на Re: Doc patch, further describe and-mask nature of the permission system  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On 12/16/2012 12:56:22 AM, Peter Eisentraut wrote:
> On Mon, 2012-12-10 at 20:48 -0600, Karl O. Pinc wrote:
> > On 11/14/2012 02:35:54 PM, Karl O. Pinc wrote:
> > > On 11/13/2012 08:50:55 PM, Peter Eisentraut wrote:
> > > > On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
> > > > > This patch makes some sweeping statements.
> > > >
> > > > Unfortunately, they are wrong.
> > >
> > > I will see if anything can be salvaged.
> >
> > Here's another try.
> > (I bundled changes to both paragraphs into a single
> > patch.)
> >
> > grants-of-roles-are-additive_v3.patch
>
> I don't get the point of this change, especially why you are trying
> to
> liken the roles system to the object hierarchy, when they are clearly
> different and unrelated.

It seems to me the that the permission system follows the object system
hierarchy in those cases where different levels of the object
hierarchy may have identical permissions.  The exceptions being
permissions like USAGE, which seems to be a convenient common lexical
token but mean (and need to mean) something entirely different
at each level of the object hierarchy.   ALL is also confuses the
issue, since it means "all permissions which work at this level
of the object hierarchy" and not "all permissions" so, say,
granting ALL to a database says nothing about INSERT permission.

I'm (clearly) not steeped in the pg permission system, but it
does seem that where permissions are "shared" between levels
of the object hierarchy there is a consistency in the
resulting interaction when granting/revoking at different
levels of the object hierarchy.  Perhaps this is ipso facto
(counterexamples being automatically designated as
"not shared" by nature of the premise :)
or perhaps more an artifact of my attention than the
result of any sort of design.  Anyway, my intent is to point
out this consistency.  Since the way in which interactions
between permissions set at different levels of the object
hierarchy is sometimes useful I go on to describe how to
replicate the behavior and apply it outside the object
hierarchy.

In any case I thought the elaboration would be helpful.
I had a few minutes and cooked it up.  If you don't don't think
it should go in then reject it.  As noted already in the
docs, permissions are different at different levels of the
object hierarchy, but similar enough to describe in one place.
I was hoping to provide a possible framework for thinking
about permission interactions between object hierarchy levels
where such occur.  Without any sort of framework everything
becomes a special case and it's hard to keep track of.

Thanks for spending time on it.  If there's anything about
it that appeals then I will continue to work under
your direction.

Regards,

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."                -- Robert A. Heinlein





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: multiple CREATE FUNCTION AS items for PLs
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: multiple CREATE FUNCTION AS items for PLs