Thread: 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@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. 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@ak.jp.nec.com>
Attachment
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. -- 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@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. So, I'd like to fix the problem. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com>
2010/8/17 KaiGai Kohei <kaigai@ak.jp.nec.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@ak.jp.nec.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@ak.jp.nec.com>
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. -- 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@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. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com>
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
(2010/08/17 10:57), Robert Haas wrote: > 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. > 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@ak.jp.nec.com>
2010/8/16 KaiGai Kohei <kaigai@ak.jp.nec.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@ak.jp.nec.com>