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
