Re: shared_preload_libraries is ignored in single user mode - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: shared_preload_libraries is ignored in single user mode |
Date | |
Msg-id | AANLkTimSoRjhRHiVvA8CCrnAeUz6RRn8AY3BYLWWPo4n@mail.gmail.com Whole thread Raw |
In response to | Re: shared_preload_libraries is ignored in single user mode (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Responses |
Re: shared_preload_libraries is ignored in single user
mode
|
List | pgsql-hackers |
2010/8/16 KaiGai Kohei <kaigai@ak.jp.nec.com>: > (2010/08/17 9:52), Robert Haas wrote: >> 2010/8/16 KaiGai Kohei<kaigai@ak.jp.nec.com>: >>> (2010/08/16 23:40), Robert Haas wrote: >>>> 2010/8/16 KaiGai Kohei<kaigai@ak.jp.nec.com>: >>>>> Although nobody paid an attention, it seems to me a problem to be fixed. >>>>> >>>>> The attached patch fixes the problem using a simple idea which adds >>>>> process_shared_preload_libraries() at PostgresMain() when we launched >>>>> it in single-user mode. >>>> >>>> I have no confidence at all that this is a sane thing to do. I think >>>> any enhanced security provider that needs system objects to be >>>> labelled should provide a script to label them after the fact. You >>>> can't count on everyone who wants to use SE-PostgreSQL having made >>>> that decision at initdb time. I think we want to keep single-user >>>> mode as lean and mean as possible, so that people can rely on it when >>>> they need to fix their broken database. >>>> >>> I also agree it is nonsense to make access control decision during >>> initdb phase, but it is not the reason why I want to fix this problem. >>> >>> I plan to provide a script that assigns initial security label after >>> the initdb, but before launching postmaster. This script tries to execute >>> postgres in single-user mode, then labels database objects according to >>> the system setting. But the sepgsql module is not loaded currently. >>> >>> I want to kick this job in single-user mode, not normal processing mode, >>> because we can simplify several stuffs. For example, we don't need to >>> check whether the user has privilege to assign initial labels, because >>> it is obvious people who launch initdb has superpower on whole of the >>> database. In addition, we don't need to consider a possibility that >>> someone create a new database object during initial labeling. >> >> I think this is a bad design. Consider someone who has 10 databases >> for which he does NOT wish to use security labelling. One day he >> decides to create database #11 and on this one he DOES want security >> labelling. Ideally, he'd be able to do this without shutting down the >> database. Of course, that's not going to quite work, since >> shared_preload_libraries needs to be changed, but that can be done >> with a very quick server bounce. Requiring him to run the setup >> scripts in single-user mode is just painful; forcing him to label >> every database is even worse. >> > Hmm. It seems to me a reasonable scenario indeed. > In this case, the someone who wants to create #11 database with security > labels may connect on the postmaster via internet, so we need to check > his privileges to assign security label on individual database objects > without short-cut like a case when single-user mode. > > Perhaps, the best one is to provide two options for users. > If he wants to label database obejcts just after initdb, he can launch > a script to label them in single-user mode; without any cumbers. > If he wants to label only objects within database #11 after several > months from initdb, he can launch a script to label them via normal > connection. I don't really see what the advantage of doing this in single-user mode is. If the overhead of permissions-checking is enough to matter, maybe that's a sign we're doing something wrong. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
pgsql-hackers by date: