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: pgsql-patches-owner(at)postgresql(dot)org
> [mailto:pgsql-patches-owner(at)postgresql(dot)org] On Behalf Of
> Magnus Hagander
> Sent: Saturday, January 14, 2006 6:09 PM
> To: pgsql-patches(at)postgresql(dot)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"
>