Re: Updates of SE-PostgreSQL 8.4devel patches (r1704) - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Updates of SE-PostgreSQL 8.4devel patches (r1704) |
Date | |
Msg-id | 603c8f070903091200p73ba8d16k7ec125425b3df04e@mail.gmail.com Whole thread Raw |
In response to | Re: Updates of SE-PostgreSQL 8.4devel patches (r1704) (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Updates of SE-PostgreSQL 8.4devel patches (r1704)
|
List | pgsql-hackers |
On Mon, Mar 9, 2009 at 1:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > KaiGai Kohei <kaigai@kaigai.gr.jp> writes: >> Yes, the purpose of sepgsqlCheckProcedureInstall() is to prevent users >> to invoke functions installed by other malicious/untrusted one, typically >> known as trojan-horse. >> ... >> We should not assume only C-functions can be installed on pg_conversion >> (and other internal stuff), because a superuser can update system catalog >> by hand. >> ... >> SE-PostgreSQL intends to acquire them and apply access control policy >> in this case also. > > I don't think that anyone except KaiGai-san has bought into the concept > that sepostgres should get to override superuser capabilities, much less > that it should be trying to control semantics at this kind of level of > detail. I'd find that VERY surprising. One of the major features of MAC systems is that the system policy trumps decisions by individual users, so root or the database superuser is confined by that policy just like everyone else. They may or may not have the ability to change the policy, but that's a separate issue. > I've been convinced for awhile that the sepostgres project is going > off the rails, and these last couple of exchanges just confirm the fear. I'm not sure what you mean by "going off the rails". I think we are still beating our way through what Peter Eisentraut said in one of his first reviews of this patch: SE-PostgreSQL shouldn't implement MAC that isn't a mirror of existing DAC capabilities. If more capabilities are needed, the DAC side of things should be designed and implemented first. Interestingly, Heikki's latest review comments are coming back to exactly this point. So I think we have unanimity that everything that doesn't meet this criterion should be ripped out for now. But I don't see anyone arguing that those capabilities are intrinsically worthless, except possibly you, just that we won't be ready to support them in SE-PostgreSQL until we support them in some more general sense. > This is absolutely *not* the kind of thing that we should be designing > four months after feature freeze. On this point I am in agreement. We need very much to bring this "November" CommitFest to an end. Unfortunately, the pace of reviewing slowed dramatically after Thanksgiving and has since dropped to a crawl. However, since the decision to bump Hot Standby was made, things have picked up again, mostly due to a bunch of reviewing by Heikki. The thing we need to do now is make that reviewing reach some conclusion about exactly what needs to be fixed and what of it will be fixed by the author vs. by the committer. It would be easier to make the decision to bump SE-PostgreSQL if it were the only thing holding up beta, but we're not there yet. ...Robert
pgsql-hackers by date: