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.


> -----Original Message-----
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Magnus Hagander
> Sent: Saturday, January 14, 2006 6:09 PM
> To:
> 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

Reply via email to