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
Show quoted text
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org] 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 win32Attached 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 startingD:\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"
"Magnus Hagander" <mha@sollentuna.net> 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
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
Import Notes
Resolved by subject fallback
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 19073You'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
Show quoted text
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]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 anytime 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
Import Notes
Resolved by subject fallback
"Magnus Hagander" <mha@sollentuna.net> 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
Tom Lane wrote:
"Magnus Hagander" <mha@sollentuna.net> 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 19073You'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
Import Notes
Resolved by subject fallback