Re: shared_preload_libraries is ignored in single user mode

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: shared_preload_libraries is ignored in single user mode
Дата
Msg-id AANLkTimSoRjhRHiVvA8CCrnAeUz6RRn8AY3BYLWWPo4n@mail.gmail.com
обсуждение исходный текст
Ответ на Re: shared_preload_libraries is ignored in single user mode  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Ответы Re: shared_preload_libraries is ignored in single user mode  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Список 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 по дате отправления:

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: shared_preload_libraries is ignored in single user mode
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Git migration timeline