Re: Fix for initdb failures on Vista
От | Andrew Dunstan |
---|---|
Тема | Re: Fix for initdb failures on Vista |
Дата | |
Msg-id | 47C7957F.10304@dunslane.net обсуждение исходный текст |
Ответ на | Fix for initdb failures on Vista ("Dave Page" <dpage@pgadmin.org>) |
Ответы |
Re: Fix for initdb failures on Vista
|
Список | pgsql-patches |
Dave Page wrote: > The attached patch fixes problems reported primarily on Vista, but > also on some Windows 2003 and XP installations in which initdb reports > that it cannot find postgres.exe. > > This occurs because of security-related changes implemented in Windows > Vista and recent patches on older OS's. When running initdb or pg_ctl > we currently create a restricted security token with the > Administrators and Power Users groups (and thus their privileges) > removed and re-execute the same program using the restricted token. > This ensures that the process is run without potentially dangerous > privileges no matter what user account it was started from. On Vista > and friends however, the default DACL (list of Access Control Entries) > used in the restricted token contains Administrators (the group) & > System when we run as Administrator, vs. User + System when run as > other users. Because we then drop Administrators, we are left with > only the System ACE in the DACL, which does not allow us to use > CreatePipe()/CreateProcess(). > > To fix this, when we create the restricted process, we initially start > it in suspended mode. We modify it's DACL to explicitly add an ACE for > the current user, and then resume the child process. This remains > secure because administrative privileges are granted to the groups > that we've dropped, not the user itself. > > I've tested on Vista and XP, but additional testing would be useful > (Andrew, Magnus?). Please apply to head, 8.3 and 8.2 > > This appears to work for initdb. But "make check" fails after the initdb stage, I think because pg_regress doesn't use pg_ctl to start the postmaster. The log just reads "Access is denied'" I don't have too much difficulty with that as long as we stipulate that postgres has to be built, or at least checked, as a non-privileged user (c.f. recent discussion of building RPMs as root). Alternatively, we should also patch pg_regress.c cheers andrew
В списке pgsql-patches по дате отправления: