Re: Re: BUG #6652: Installer grants postgres user rights for the whole disk, not specified subfolder

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Trey Chadick <tchad(at)labkey(dot)com>
Cc: Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Re: BUG #6652: Installer grants postgres user rights for the whole disk, not specified subfolder
Date: 2012-07-17 07:16:30
Message-ID: CA+OCxoz6tih=KEMti8v+sW+-HW6L+xzFfER95kna6b57aWZgmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Jul 17, 2012 at 12:01 AM, Trey Chadick <tchad(at)labkey(dot)com> wrote:
> Excerpts from Dave Page's message of mar jun 05 14:38:54 -0400 2012:
>>
>> On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera
>> <alvherre(at)commandprompt(dot)com> wrote:
>
>> >> I have been installing PostgreSQL 9.1.3.2, and I've noted that 'creating
>> >> database cluster' is too long. I have been waiting for a half of hour, and
>> >> it hasn't finished.
>> >> I've noted that installer calls icacls.exe with arguments:
>> >> D:\ /grant "postgres":RX
>> >
>> > This seems to be reported every once in a while. It looks like the
>> > one-clunk installer is to blame. Maybe it's been fixed in some more
>> > recent version -- Dave Page would probably know.
>>
>> Just as an FYI, we are working on this. We've been able to reproduce
>> it, and it appears that icacls (a Microsoft utility) will sometimes
>> look at the ACL of every file/directory recursively when it grants the
>> required privileges on higher level directories. The good news is that
>> in none of the test we've done has it ever modified the ACL on the
>> wrong thing - it just takes a long time if there are a lot of items on
>> the filesystem. We've looked at third party alternatives to icacls,
>> and they seem to exhibit similar traits. We're also going to look into
>> other ways around the root problem.
>
>
> The 9.1.4 installer is still exhibiting this behavior; not as bad as
> the original bug, but still pushing 30 minutes. Has there been any
> luck with finding a work-around?

Not really, other that removing the check which was specifically added
to alleviate issues others saw.

However, with 9.2 we're changing the default service account to NT
AUTHORITY\NetworkService, which likely doesn't need the check anyway.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit kapila 2012-07-17 08:59:50 Re: BUG #6712: PostgreSQL 9.2 beta2: alter table drop constraint does not work on inherited master table
Previous Message Tom Lane 2012-07-17 02:15:35 Re: BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)