Re: shared_preload_libraries is ignored in single user mode

(2010/08/17 10:57), Robert Haas wrote:
> 2010/8/16 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> (2010/08/17 9:52), Robert Haas wrote:
>>> 2010/8/16 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>> (2010/08/16 23:40), Robert Haas wrote:
>>>>> 2010/8/16 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)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.
>
Hmm... I guess the overhead is not a significant matter, because the
number of system obejcts (not only tables) are less than 3,500.
It will be small enough on recent hardware.

I might have a reason why the script need to launch in single-user
mode, but it is not clear right now, sorry.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>