Re: [HACKERS] [PATCHES] Fix for running from admin account on win32
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Attached is a patch for initdb only (the other patch stands unchanged). > It will make initdb re-exec itself with a restricted token when > available (since we can only control the security of subprocesses) Applied to HEAD. > There's a bit of shared code with pg_ctl (but not all of the exec stuff, > because there is no need for a job object for initdb). I'm unsure if > it's worth putting something in src/port instead for it, so this version > doesn't. I agree that it seems marginal at this point. But if we find ourselves adding the functionality anyplace else, you should probably factor out the common code into a /port module. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Fix for running from admin account on win32
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Attached is a two part patch for the admin functionality on win32. > The first part is a simple bugfix to backend/port/win32/security.c. The > function that checks if the user has admin privileges didn't check it > the SID in the token was enabled or not. Applied back to 8.0. > The second part enables pg_ctl to give up admin privleges when starting > the server. Applied to HEAD only. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Fix for running from admin account on win32
> > Fine. I just wanted to make sure the decions was being made > in terms > > of logic, rather than Win32 cruft avoidance. The previous > discussion > > was not clear on this point. > > I just came across another problem with this patch. It's not > complete :( > > You can *run* postgresql fine with it, but you can't run > initdb. Oops. > > I'll look at completing it with an update to initdb. There's nothing > *wrong* with the patch that's in the queue now (that I know > of, of course), so this is just an extension to it. Attached is a patch for initdb only (the other patch stands unchanged). It will make initdb re-exec itself with a restricted token when available (since we can only control the security of subprocesses) There's a bit of shared code with pg_ctl (but not all of the exec stuff, because there is no need for a job object for initdb). I'm unsure if it's worth putting something in src/port instead for it, so this version doesn't. //Magnus initdb_restricted.patch Description: initdb_restricted.patch ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Fix for running from admin account on win32
> > > You'll still need to run the postmaster frmo pg_ctl to > get the "run > > > as admin" part. The only part that could be moved is the > Job Object > > > for management. And you're normally not going to need > that one when > > > you're not running as a service. Maybe sometimes, but I > doubt it's > > > worth it. If we could solve the run-as-admin inside the > postmaster > > > it might be different, but AFAICS we can't. > > > > Yeah, I thought we'd agreed that the patch was fine as-is. > > Fine. I just wanted to make sure the decions was being made > in terms of logic, rather than Win32 cruft avoidance. The > previous discussion was not clear on this point. I just came across another problem with this patch. It's not complete :( You can *run* postgresql fine with it, but you can't run initdb. Oops. I'll look at completing it with an update to initdb. There's nothing *wrong* with the patch that's in the queue now (that I know of, of course), so this is just an extension to it. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Fix for running from admin account on win32
Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > > You'll still need to run the postmaster frmo pg_ctl to get the "run as > > admin" part. The only part that could be moved is the Job Object for > > management. And you're normally not going to need that one when you're > > not running as a service. Maybe sometimes, but I doubt it's worth it. If > > we could solve the run-as-admin inside the postmaster it might be > > different, but AFAICS we can't. > > Yeah, I thought we'd agreed that the patch was fine as-is. Fine. I just wanted to make sure the decions was being made in terms of logic, rather than Win32 cruft avoidance. The previous discussion was not clear on this point. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] Fix for running from admin account on win32
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > You'll still need to run the postmaster frmo pg_ctl to get the "run as > admin" part. The only part that could be moved is the Job Object for > management. And you're normally not going to need that one when you're > not running as a service. Maybe sometimes, but I doubt it's worth it. If > we could solve the run-as-admin inside the postmaster it might be > different, but AFAICS we can't. Yeah, I thought we'd agreed that the patch was fine as-is. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Fix for running from admin account on win32
You'll still need to run the postmaster frmo pg_ctl to get the "run as admin" part. The only part that could be moved is the Job Object for management. And you're normally not going to need that one when you're not running as a service. Maybe sometimes, but I doubt it's worth it. If we could solve the run-as-admin inside the postmaster it might be different, but AFAICS we can't. //Magnus > -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > > Where are we on this patch? > > I am thinking it should be in the most logical place, rather > than in pg_ctl. One call isn't a big deal, especially if you > can run the postmaster without using pg_ctl. > > -- > - > > Magnus Hagander wrote: > > > > If the job object code is moved to the postmaster, it'll > > > work when not > > > > running as a service as well. > > > > > > I'd just as soon keep all that Windows-specific cruft in pg_ctl. > > > So I think the way you've got it set up is fine. > > > > Well, it'd all be localised to the backend/port/win32 directory of > > course, except for a single call - where there is already "windows > > cruft". > > > > But. I see your point. And the vast majority of production > > installations run as service anyway. So I won't spend any > time making > > those changes, I'll leave what's on -patches now. > > > > //Magnus > > > > ---(end of > > broadcast)--- > > TIP 5: don't forget to increase your free space map settings > > > > -- > Bruce Momjian| http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, > Pennsylvania 19073 > ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Fix for running from admin account on win32
Where are we on this patch? I am thinking it should be in the most logical place, rather than in pg_ctl. One call isn't a big deal, especially if you can run the postmaster without using pg_ctl. --- Magnus Hagander wrote: > > > If the job object code is moved to the postmaster, it'll > > work when not > > > running as a service as well. > > > > I'd just as soon keep all that Windows-specific cruft in pg_ctl. > > So I think the way you've got it set up is fine. > > Well, it'd all be localised to the backend/port/win32 directory of > course, except for a single call - where there is already "windows > cruft". > > But. I see your point. And the vast majority of production > installations run as service anyway. So I won't spend any time making > those changes, I'll leave what's on -patches now. > > //Magnus > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Fix for running from admin account on win32
> > If the job object code is moved to the postmaster, it'll > work when not > > running as a service as well. > > I'd just as soon keep all that Windows-specific cruft in pg_ctl. > So I think the way you've got it set up is fine. Well, it'd all be localised to the backend/port/win32 directory of course, except for a single call - where there is already "windows cruft". But. I see your point. And the vast majority of production installations run as service anyway. So I won't spend any time making those changes, I'll leave what's on -patches now. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Fix for running from admin account on win32
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > If the job object code is moved to the postmaster, it'll work when not > running as a service as well. I'd just as soon keep all that Windows-specific cruft in pg_ctl. So I think the way you've got it set up is fine. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Fix for running from admin account on win32
Naturally, just a minute after sending the patch, I realised how it can be done better ;) If the job object code is moved to the postmaster, it'll work when not running as a service as well. And there's no way to break out of the job object - it's just the other part. Yes, I'll set up a new patch :-) Meanwhlie, if there are any other comments on this one, I'm still interested in those. //Magnus > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Magnus Hagander > Sent: Saturday, January 14, 2006 6:09 PM > To: pgsql-patches@postgresql.org > Subject: [PATCHES] Fix for running from admin account on win32 > > Attached is a two part patch for the admin functionality on win32. > > The first part is a simple bugfix to > backend/port/win32/security.c. The function that checks if > the user has admin privileges didn't check it the SID in the > token was enabled or not. All actual access checks done by > the OS does check this, so we should too :-) This is required > for the second part of the patch to work, but also in some > scenarios with third-party tools that modify the token. > > > The second part enables pg_ctl to give up admin privleges > when starting the server. This works for both standalone and > service, but only when running on Windows 2000 or newer. The > APIs simply didn't exist in NT4. > pg_ctl still works in NT4, but is unable to give up > privileges. Since we still do the privilege check in the > postmaster, this is not a problem. > This has to be implemented in pg_ctl, because if it's done > in-process it's possi ble to get the admin privs back. > > It also implements a job object wrapper around all processes created. > This only works when running as a service, because the job > object is destroyed when pg_ctl exits (it's automatically > destroyed when the last handle is closed). However, when > running as a service it increases security further by > preventing new processes from being started with a different > user, access to clipboard, windows restarting and desktop > access. It also limits further any chance of accessing admin > privileges, more than we have today. > > Finally, the job object provides an excellent point for > monitoring the server. It will contain aggregate statistics > of how many processes are running (or have been running), how > much CPU is being used (has been used), memory activity etc. > As a whole for postmaster+all children, not one a piece. This > functionality is all provided by default by the windows > performance monitor when you use job objects. > > > It turned out the mingw headers *and* libraries were > incomplete wrt these functions, so I had to do it with > runtime loading of DLLs. Since I had to do this anyway, it > was trivial to do this for all the NT4 functions, and just > have it work there. So the discussion I started yesterday > about NT4 compatibility doesn't really apply to this case - > but it's still a good discussionto have I think. > > > //Magnus > > > D:\msys\1.0\local\pgsql\bin>postmaster -D ..\data Execution > of PostgreSQL by a user with administrative permissions is > not permitted. > The server must be started under an unprivileged user ID to > prevent possible system security compromises. See the > documentation for more information on how to properly start > the server. > > D:\msys\1.0\local\pgsql\bin>pg_ctl -D ..\data start > postmaster starting > > D:\msys\1.0\local\pgsql\bin>LOG: database system was shut down at > 2006-01-14 17 > :42:14 W. Europe Standard Time > LOG: checkpoint record is at 0/39FD88 > LOG: redo record is at 0/39FD88; undo record is at 0/0; shutdown TRUE > LOG: next transaction ID: 582; next OID: 16389 > LOG: next MultiXactId: 1; next MultiXactOffset: 0 > LOG: database system is ready > LOG: transaction ID wrap limit is 2147484146, limited by > database "postgres" > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Fix for running from admin account on win32
Attached is a two part patch for the admin functionality on win32. The first part is a simple bugfix to backend/port/win32/security.c. The function that checks if the user has admin privileges didn't check it the SID in the token was enabled or not. All actual access checks done by the OS does check this, so we should too :-) This is required for the second part of the patch to work, but also in some scenarios with third-party tools that modify the token. The second part enables pg_ctl to give up admin privleges when starting the server. This works for both standalone and service, but only when running on Windows 2000 or newer. The APIs simply didn't exist in NT4. pg_ctl still works in NT4, but is unable to give up privileges. Since we still do the privilege check in the postmaster, this is not a problem. This has to be implemented in pg_ctl, because if it's done in-process it's possi ble to get the admin privs back. It also implements a job object wrapper around all processes created. This only works when running as a service, because the job object is destroyed when pg_ctl exits (it's automatically destroyed when the last handle is closed). However, when running as a service it increases security further by preventing new processes from being started with a different user, access to clipboard, windows restarting and desktop access. It also limits further any chance of accessing admin privileges, more than we have today. Finally, the job object provides an excellent point for monitoring the server. It will contain aggregate statistics of how many processes are running (or have been running), how much CPU is being used (has been used), memory activity etc. As a whole for postmaster+all children, not one a piece. This functionality is all provided by default by the windows performance monitor when you use job objects. It turned out the mingw headers *and* libraries were incomplete wrt these functions, so I had to do it with runtime loading of DLLs. Since I had to do this anyway, it was trivial to do this for all the NT4 functions, and just have it work there. So the discussion I started yesterday about NT4 compatibility doesn't really apply to this case - but it's still a good discussionto have I think. //Magnus D:\msys\1.0\local\pgsql\bin>postmaster -D ..\data Execution of PostgreSQL by a user with administrative permissions is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromises. See the documentation for more information on how to properly start the server. D:\msys\1.0\local\pgsql\bin>pg_ctl -D ..\data start postmaster starting D:\msys\1.0\local\pgsql\bin>LOG: database system was shut down at 2006-01-14 17 :42:14 W. Europe Standard Time LOG: checkpoint record is at 0/39FD88 LOG: redo record is at 0/39FD88; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 582; next OID: 16389 LOG: next MultiXactId: 1; next MultiXactOffset: 0 LOG: database system is ready LOG: transaction ID wrap limit is 2147484146, limited by database "postgres" postmster_win32_admincheck.patch Description: postmster_win32_admincheck.patch pg_ctl_win32_priv.patch Description: pg_ctl_win32_priv.patch ---(end of broadcast)--- TIP 6: explain analyze is your friend
