On Wed, Oct 21, 2009 at 8:45 AM, Dave Page <dp...@pgadmin.org> wrote:
> On Tue, Oct 20, 2009 at 5:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
>> Seems like it would be worth the trouble to identify exactly what the
>> critical difference is.
>
> Given Jesse's description of the systems he's seen this on, I suspect
> we'll be very lucky if we pin that down, unless it is something as
> simple as win2k3+administrator+command line (which I'll try to test
> shortly) - but that doesn't tally with the occasional cases of this I
> still hear about (usually from our poker-playing users) who are using
> the installer and Vista or XP as a general rule.
I tested in 2k3, and was surprised to see that whilst initdb worked
fine in 8.4.1 (that's where the problem traditionally shows up),
starting the server failed:
C:\pgsql>bin\pg_ctl -D data start
server starting
C:\pgsql>FATAL: XX000: C:/pgsql/bin/postgres.exe: could not locate
matching postgres executable
LOCATION: getInstallationPaths, .\src\backend\postmaster\postmaster.c:1070
Jesse's patched version works as it should. This makes it clear that
the re-factoring of the way the security token is created and the
process started is not the really important part of this patch - this
is:
- if (!AddAccessAllowedAce(pacl, ACL_REVISION, GENERIC_ALL, psidUser))
- {
+ if (!AddAccessAllowedAceEx(pacl, ACL_REVISION, OBJECT_INHERIT_ACE,
GENERIC_ALL, psidUser))
+ {
This function call is adding the new access control entry to the DACL,
and in Jesse's modified version it's specifying that the ACE should be
inheritable.
The other refactoring is still important however - without it, I still
see the error. I would guess that you cannot add an inheritable ACE
once the process has been created, but I cannot say for certain.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
