Re: security hook on table creation

(2010/10/18 23:14), Robert Haas wrote:
>> If MVCC visibility always would match with existing permission checks,
>> we don't need to pay special attention for these things, do we?
>
> It seems to me that you're worrying about the wrong set of problems.
> The original purpose of what I proposed was to let you set a security
> context on a new object at creation time, not to provide fine-grained
> DDL access control. I thought perhaps we could kill two birds with
> one stone, but if not, let's take three steps back and assume that DDL
> permissions will be controlled using a coarse-grained check installed
> in ProcessUtility_hook, so that by the time these hooks get installed
> they have no job except to apply any necessary label.
>
Ah, yes, the original or primary purpose was automatic assignment of
security labels at creation time. Access controls on CREATE statement
is a second bird, indeed.
I agree with the idea to separate things corresponding to DDL permission
checks right now. I'll focus on the creation-time hooks to fix up
security label (or something depending on security models) on the
next commit fest.

At least, ProcessUtility_hook is too coarse-grained to implement full-
set of functionalities that we expect, so we will have a discussion about
what is the preferable design of access control hooks in the future.
But it is not right now.

> But as to your question, nothing whatever excuses you from needing to
> worry about MVCC. The entire backend is littered with things that
> have to worry about MVCC. Whether there's a concern for any
> particular bit of code depends heavily on what that code does, but "I
> put it in the same place so I needn't worry" is only true if you're
> doing the same thing, which you may not be. Nor is it correct to
> suppose that doing permissions checking the way you're proposing is
> going to somehow be free of code maintenance concerns. Indeed, many
> of the patches you've submitted in this area have been rejected
> precisely because they would make the code quite difficult to maintain
> - for example, by passing bits of no obvious relevance to the hooks.
>
Hmm. Indeed, we have many things which need to be carefully implemented,
not only access control stuff. Perhaps, it is right. So, author of plugin
modules need to pay attention even if minor updates.

However, MVCC visibility is one of the issues we need to pay attentions.
As you mentioned about, I have a bad memory about difficulty to maintain
the code. The existing permission checks are reviewed by larger number of
eyeballs than author of enhanced security modules.
So, I believe it eventually reduce burden to maintain, and enables to
overlook code-paths that bypass the upcoming DDL permission checks.

Anyway, let's have a discussion when we put security hooks for DDL checks.
But the next patch will focus on assignment of security label at object
creation.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>