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:
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
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áb may 19 10:28:47 -0400 2012:
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: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.
--
Álvaro 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áb may 19 10:28:47 -0400 2012:
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: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":RXThis 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.
--
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:
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 '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":RXThis 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.
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.
--
Álvaro 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 '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":RXThis 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.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.
--
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 directory) was passed by installer to icacls. That's what I saw. It wasn't problem of icacls, it was a problem in pgsql installer.
05.06.2012, 22:38, "Dave Page" <dpage@pgadmin.org>:
Show quoted text
On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:Excerpts from grv87's message of sáb may 19 10:28:47 -0400 2012:
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: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":RXThis 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.
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's what 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