Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED - Mailing list pgsql-hackers

> 
> Have you done anything special to your mingw install?

The only thing different is that I upgraded to the latest mingw and msys 
packages a couple of weeks ago.  The other thing I can think of is that 
I installed openssl and related packages (the official ones from the 
msys project).  Would that force ENABLE_SSPI to be set or is it always 
set (and is it set in the build farm)?

>> Second, once I've successfully built and installed postgres, I run into
>> a bigger problem.  When using initdb, I get this error:
>>
>> creating template1 database in c:/Data/postgres30/base/1 ... FATAL:
>> could not create shared memory segment: 5
>> DETAIL:  Failed system call was CreateFileMapping(size=1802240,
>> name=Global\PostgreSQL:c:/Data/postgres).
>>
>> A bit of googling and reading MSDN docs shows that applications that
>> don't run in Session 0 on Vista are not allowed to create shared memory
>> in the Global namespace.  Since initdb is invoked from the command line,
>> it runs in Session 1.
> 
> Where did you find that information? I've been specifically looking for
> it, but my searches didn't turn up anything conclusive.

Yeah, information is scattered and came mostly through reading MSDN 
forum posts.  It seems a number of people have been bitten by this 
change to createFileMapping in Vista. My searches:

http://www.google.com/search?hl=en&q=createfilemapping+access_denied+vista&btnG=Search
http://www.google.com/search?hl=en&q=createfilemapping+SeCreateGlobalPrivilege+&btnG=Search

In particular, the session 0 information is documented at:

http://msdn.microsoft.com/en-us/library/aa366537(VS.85).aspx

Quoting:

> The name can have a "Global\" or "Local\" prefix  to explicitly create the object in the global or session
namespace...creatinga file mapping object in the global namespace from a session other than session zero requires the
SeCreateGlobalPrivilegeprivilege.
 

And more here:

http://msdn.microsoft.com/en-us/library/aa480152.aspx#appcomp_topic12

And this blog post might be helpful:

http://www.celceo.com/blogs/windows-insight/2007/09/global-createfilemapping-under.html

Towards the bottom it says:

> Additionally, of course, we need to create everything with the appropriate security 
attributes.  Null Dacls don't grant global access in Vista, so we need 
to create
a real security descriptior and add an ACE with GENERIC_ALL privileges 
for the world SID.

So - clearly initdb needs the SeCreateGlobalPrivilege  permission.  But 
I gave the user that runs initdb that permission using the Local 
Security Policy Editor, so something else is going on.  My first guess 
was that the initdb code had to also request that permission also, but 
that theory seems unlikely to be correct since the official win32 
binaries seem to work fine (I'm assuming they are the exact same code??)

> The latest versions contain a fix for the global namespace code. Dave
> noticed that this caused issues on vista and thus manually reverted the
> patch in the official binary installer. But since we haven't (hadn't)
> yet found documentation as to *why* it was failing, the patch has not
> yet been reverted in the main source tree.
> 
> This is why it's working, probably, and it's not related to how it's built.

Ah - so the trunk code is different than the binary release code?  That 
would explain it.  And in that case, then maybe the solution is setting 
up the security descriptor for calling createFileMapping?

> 
> If you want to revert the patch in your local tree, this is the one:
> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/port/win32_shmem.c?r1=1.4&r2=1.5
> 
> Specifically, you can reintroduce the old bug (that I think is hat made
> it work on Vista) by removing the +18 in the lowest loop there.

Ok, I just reverted the whole patch (so all 4 changes), did a make clean 
; make; make install.  And no dice, I'm still having the same issue.

Thanks,

Charlie

-- 
Charlie Savage
http://cfis.savagexi.com