Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Fix for running from admin account on win32

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: <pgsql-hackers(at)postgresql(dot)org>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [PATCHES] Fix for running from admin account on win32
Date: 2006-01-14 18:09:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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-----
> 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"


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-01-14 18:44:19
Subject: Re: [PATCHES] Fix for running from admin account on win32
Previous:From: Denis LussierDate: 2006-01-14 16:40:46
Subject: Re: PG process architecture

pgsql-patches by date

Next:From: Tom LaneDate: 2006-01-14 18:44:19
Subject: Re: [PATCHES] Fix for running from admin account on win32
Previous:From: Magnus HaganderDate: 2006-01-14 17:09:44
Subject: Re: pg_ctl crash fix

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group