Re: shared_preload_libraries is ignored in single user mode

I found out "shared_preload_libraries" setting is ignored when we launch
postgres in single user mode.

In this case, postgres command is launched with "--single" argument,
then the main() directly invokes PostgresMain(); without going through
PostmasterMain() which calls process_shared_preload_libraries().

I think we should put the following code block on somewhere within
PostgresMain() to fix up it.

/*
* If not under postmaster, shared preload libraries are not
* loaded yet, so we try to load them here.
*/
if (!IsUnderPostmaster)
process_shared_preload_libraries();

The reason why I want to use modules in single user mode is to assign
initial security labels on database objects just after initdb.
But, the GUC is ignored, we cannot invokes the routines in the module. :(

Thanks,
--
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.

Thanks,

(2010/08/05 15:08), KaiGai Kohei wrote:
> I found out "shared_preload_libraries" setting is ignored when we launch
> postgres in single user mode.
>
> In this case, postgres command is launched with "--single" argument,
> then the main() directly invokes PostgresMain(); without going through
> PostmasterMain() which calls process_shared_preload_libraries().
>
> I think we should put the following code block on somewhere within
> PostgresMain() to fix up it.
>
> /*
> * If not under postmaster, shared preload libraries are not
> * loaded yet, so we try to load them here.
> */
> if (!IsUnderPostmaster)
> process_shared_preload_libraries();
>
> The reason why I want to use modules in single user mode is to assign
> initial security labels on database objects just after initdb.
> But, the GUC is ignored, we cannot invokes the routines in the module. :(
>
> Thanks,

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

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

(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.

So, I'd like to fix the problem.

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

2010/8/17 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> I want to kick this job in single-user mode, not normal processing mode,

Does an explicit LOAD work in single-user mode?
I think LOAD just after login works as same as it was preloaded,
unless it allocates shared memory.

--
Itagaki Takahiro

(2010/08/17 9:02), Itagaki Takahiro wrote:
> 2010/8/17 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> I want to kick this job in single-user mode, not normal processing mode,
>
> Does an explicit LOAD work in single-user mode?
> I think LOAD just after login works as same as it was preloaded,
> unless it allocates shared memory.
>
Thanks, I never thought this idea.

It works and solves the matter, but I think the right way is to fix
the problem, rather than a workaround in scripts...

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

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

(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.

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

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

(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>

2010/8/16 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> 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 would think so. More to the point, what is the cost of checking
permissions as a percentage of the cost of applying the new labels?
If it isn't pretty small, something's not right. Performance will
probably be terrible if anyone actually attempts to use this do to
real work.

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

Another point here is that I wonder if we really need to label system
objects at all. Are you applying the same label to all of them? If
so, perhaps it might be feasible to set up the code so that it simply
assumes that label for every object in the pg_catalog namespace.

And if you're NOT setting the label the same way on all of them, then
there's a maintenance issue to think about.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

(2010/08/17 11:37), Robert Haas wrote:
>> I might have a reason why the script need to launch in single-user
>> mode, but it is not clear right now, sorry.
>
> Another point here is that I wonder if we really need to label system
> objects at all. Are you applying the same label to all of them? If
> so, perhaps it might be feasible to set up the code so that it simply
> assumes that label for every object in the pg_catalog namespace.
>
No, SELinux provides APIs to suggest what database object should have
what security label on initialization time.
(selabel_open(3), selabel_lookup(3) and selabel_close(3))

It depends on configurations by system admin, so we cannot assume
a certain label for every object in a certain namespace.

> And if you're NOT setting the label the same way on all of them, then
> there's a maintenance issue to think about.
>
Right, I don't want to have multiple way to label them.

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