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

The following bug has been logged on the website:

Bug reference:      6652
Logged by:          Basil Peace
Email address:      grv87@yandex.ru
PostgreSQL version: 9.1.3
Operating system:   Windows 7 x64
Description:=20=20=20=20=20=20=20=20

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=20

My database is wanted to be in D:\Sys\pgsql-data
There is no reason for granting rights for the whole disk. I have more than
3 mln files there, and of course it could be a big waste of time.

Excerpts from grv87's message of s=C3=A1b may 19 10:28:47 -0400 2012:
> The following bug has been logged on the website:
>=20
> Bug reference:      6652
> Logged by:          Basil Peace
> Email address:      grv87@yandex.ru
> PostgreSQL version: 9.1.3
> Operating system:   Windows 7 x64
> Description:=20=20=20=20=20=20=20=20
>=20
> 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=20

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.

--=20
=C3=81lvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
>
> Excerpts from grv87's message of s=E1b may 19 10:28:47 -0400 2012:
>> The following bug has been logged on the website:
>>
>> Bug reference: =A0 =A0 =A06652
>> Logged by: =A0 =A0 =A0 =A0 =A0Basil Peace
>> Email address: =A0 =A0 =A0grv87@yandex.ru
>> PostgreSQL version: 9.1.3
>> Operating system: =A0 Windows 7 x64
>> Description:
>>
>> 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, a=
nd
>> 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. =A0It looks like the
> one-clunk installer is to blame. =A0Maybe 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.

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

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

Excerpts from Dave Page's message of mar jun 05 14:38:54 -0400 2012:
>=20
> On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:

> >> I have been installing PostgreSQL 9.1.3.2, and I've noted that 'creati=
ng
> >> 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. =C2=A0It looks like the
> > one-clunk installer is to blame. =C2=A0Maybe it's been fixed in some mo=
re
> > recent version -- Dave Page would probably know.
>=20
> 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.

Maybe you should provide some way for the user to figure out the exact
command it's running, where it's running it, and what user it runs as.=20=
=20

--=20
=C3=81lvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Tue, Jun 5, 2012 at 7:48 PM, Alvaro Herrera
<alvherre@commandprompt.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@commandprompt.com> wrote:
>
>> >> I have been installing PostgreSQL 9.1.3.2, and I've noted that 'creat=
ing
>> >> 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. =A0It looks like the
>> > one-clunk installer is to blame. =A0Maybe 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.
>
> Maybe you should provide some way for the user to figure out the exact
> command it's running, where it's running it, and what user it runs as.

Not sure why/how that would help. We know what we've told it to do,
and why - we just don't know why the Microsoft utility insists on
looking at the ACLs of files it should have no need to touch.

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

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

On Wed, Jun 6, 2012 at 8:04 PM, Basil Peace <grv87@yandex.ru> wrote:
> In my case invalid argument (root directory instead of specified data directory) was passed by installer to icacls.
That'swhat I saw. It wasn't problem of icacls, it was a problem in pgsql installer. 

That's supposed to happen. It sets the permissions on the data
directory and then recurses back up to the root directory, ensuring
the postgres account is able to read all the parent directories -
otherwise, even if it has write permissions on the data directory
itself, it cannot access it.

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

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

In my case invalid argument (root directory instead of specified data direc=
tory) was passed by installer to icacls. That's what I saw. It wasn't probl=
em of icacls, it was a problem in pgsql installer.

05.06.2012, 22:38, "Dave Page" <dpage@pgadmin.org>:
> On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>
>> =C2=A0Excerpts from grv87's message of s=C3=A1b may 19 10:28:47 -0400 20=
12:
>>> =C2=A0The following bug has been logged on the website:
>>>
>>> =C2=A0Bug reference: =C2=A0 =C2=A0 =C2=A06652
>>> =C2=A0Logged by: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Basil Peace
>>> =C2=A0Email address: =C2=A0 =C2=A0 =C2=A0grv87@yandex.ru
>>> =C2=A0PostgreSQL version: 9.1.3
>>> =C2=A0Operating system: =C2=A0 Windows 7 x64
>>> =C2=A0Description:
>>>
>>> =C2=A0I have been installing PostgreSQL 9.1.3.2, and I've noted that 'c=
reating
>>> =C2=A0database cluster' is too long. I have been waiting for a half of =
hour, and
>>> =C2=A0it hasn't finished.
>>> =C2=A0I've noted that installer calls icacls.exe with arguments:
>>> =C2=A0D:\ /grant "postgres":RX
>> =C2=A0This seems to be reported every once in a while. =C2=A0It looks li=
ke the
>> =C2=A0one-clunk installer is to blame. =C2=A0Maybe it's been fixed in so=
me more
>> =C2=A0recent 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.