Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Date
Msg-id 603c8f070809232018n56ce13caq447a330cfd098ef7@mail.gmail.com
Whole thread Raw
In response to Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (Bruce Momjian <bruce@momjian.us>)
Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>> Well, does it make sense to add column-level privileges just for
>> SE-Linux?
>
> That's the wrong question.  The question here is: does it make sense to
> have per-row permissions implemented on top of an abstraction layer
> whose sole current implementation is SE-Linux?

Er, Bruce was asking about per-column, not per-row.

There's a patch listed on CommitFest:2008-09 to introduce per-column
permissions, but it's apparently still WIP.  How much does that
overlap/conflict with these patches?

> I think the answer is yes, because (as others have said) if we ever want
> to have SQL-level per-row permissions, then we can implement them with
> no change to the patch currently in discussion.

If that's true, it weighs somewhat in favor of accepting this patch,
but how sure are we that it's really the case?  If you only have one
implementation sitting on top of your abstraction layer, it's hard to
know whether you've implemented a general framework for doing X or
merely an interface that happens to suit the particular flavor of X
that you want to do today.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Next
From: Bruce Momjian
Date:
Subject: Re: PostgreSQL future ideas