Re: How to get SE-PostgreSQL acceptable

Stephen Frost wrote:
> * KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
>> So, I cannot believe refactoring pg_xxx_aclcheck() is not acceptable.
>> If vanilla PostgreSQL become to check ACLs on tables, independent
>> from views, do you think it is acceptable?
>
> Well, just to be clear, ACLs are checked on tables under views, but
> they're checked using the privileges of the view owner rather than
> the privileges of the current user. I've run into that empirically
> because I've gotten 'permission denied' errors when using a view that
> I've clearly got full rights on but was owned by someone else (who
> didn't have rights on the table underneath).
>
> That being said, I'd think that if we do need different semantics from
> that for SE-PostgreSQL, we could implement it using a GUC or similar to
> keep the current behavior as well allow the SE-PostgreSQL behavior.

I think it is not reasonable.
If there are different philosophies, "one for one" seems to me
straight forward approach, for security especially.

>> However, we have to make clear whether the PGACE architecture
>> is incorrect, or not, at first.
>
> It really bothers me that it seems like these kinds of reviews of the
> larger patches don't happen until it's time to decide about the next
> release. Perhaps these issues were all brought up seperately in prior
> threads, or they weren't articulated as requirements or show-stoppers,
> and if so then I apologize for not following those more closely.
>
> If the approach Peter outlined is what core wants to see and is willing
> to go along with to get SE-PostgreSQL included then let's please decide
> that now and agree that unless some serious problem comes up we'll stick
> to it and not require the whole thing be rewritten again later.

As I noted, PGACE is not my goal.
I don't tremble to integrate SELinux related code into the core.

> I'm not sure about KaiGai's feelings on this, but it strikes me that
> adding SELinux support for the existing levels of access control in PG
> might be straight-forward and small enough to include for 8.4 and would
> show some commitment to this approach of "do it for PG, add SELinux
> checks for it". Alternatively, maybe a progression-towards-SE-PostgreSQL
> wiki/webpage that outlines the plan, current work, what's been
> committed, etc, that everyone reviews and agrees to?

Are you saying enlargement step-by-step, aren't you?
At least, it is far preferable to a death punishment.

I would like to here Joshua's opinion also.

> adding SELinux support for the existing levels of access control in PG

is

- table/column level access controls
- permission checks on database login
- permission checks on function invocation
- they need a facility to manage security label
- I want permission checks on loading a library,
though existing PG checks superuser() only.

and
- removing PGACE, integrate SEPG code into core
- permission checks on largeobjects is postponed
- row level security is postponed (NOT REJECTED!)
- so, writable system column is also postponed

If summary is necessary, I'll post it tommorow JST.

Because it is not a zero-based implementation, so I believe it can
be minimized within acceptable timescale.

> As a side-note, I've gotten some extremely positive feedback about
> SE-PostgreSQL from folks in my organization who run systems where it
> would be used. I'm going to be having a more detailed discussion later
> today.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>