Re: [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe

I saw a thread where somebody saw icacls.exe being called by the
one-click installer. I'm having the same thing - the installer has
been running for 45 minutes now and is basically going to have to be
stopped because I'm out of time waiting for it. Looking at process
monitor, it is clear that icacls.exe is going through every file on
the entire system and changing its permissions. The process tree
indicates that it is a child of the installer, and that it is running
the command:

icacls C:\ /grant "kawright":RX

Clearly this won't do at all and should be considered a severe installer bug.

Thanks,
Karl

On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri(at)gmail(dot)com> wrote:
> I saw a thread where somebody saw icacls.exe being called by the
> one-click installer.  I'm having the same thing - the installer has
> been running for 45 minutes now and is basically going to have to be
> stopped because I'm out of time waiting for it.  Looking at process
> monitor, it is clear that icacls.exe is going through every file on
> the entire system and changing its permissions.  The process tree
> indicates that it is a child of the installer, and that it is running
> the command:
>
> icacls C:\ /grant "kawright":RX
>
> Clearly this won't do at all and should be considered a severe installer bug.

If it does, it certainly sounds like a very bad bug.

However, according to the documentation for icacls
(http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you
should use "/t" to get it to traverse into subdirectories, and clearly
it's not doing that. So I wonder why it would go across the whole
filesystem - might tbere be a bug in icacls?

Or maybe it has something to do with inheritance? The way
inheritance-permissions works on ntfs is, um, let's call it
interesting. Maybe it needs to specify the (NP) flag to not propagate
inheritance or something?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri(at)gmail(dot)com> wrote:
>> I saw a thread where somebody saw icacls.exe being called by the
>> one-click installer.  I'm having the same thing - the installer has
>> been running for 45 minutes now and is basically going to have to be
>> stopped because I'm out of time waiting for it.  Looking at process
>> monitor, it is clear that icacls.exe is going through every file on
>> the entire system and changing its permissions.  The process tree
>> indicates that it is a child of the installer, and that it is running
>> the command:
>>
>> icacls C:\ /grant "kawright":RX
>>
>> Clearly this won't do at all and should be considered a severe installer bug.
>
> If it does, it certainly sounds like a very bad bug.
>
> However, according to the documentation for icacls
> (http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you
> should use "/t" to get it to traverse into subdirectories, and clearly
> it's not doing that. So I wonder why it would go across the whole
> filesystem - might tbere be a  bug in icacls?

Yes - that's how it's supposed to work (ie. *not* using /t). The
purpose of that code is to ensure that the entire path leading up to
the data/installation directories is readable by the users that need
it. We've had a number of reported installation failures in the past
caused by weirdness where read or execute permissions weren't
available for (for example) the service account user, which caused
somewhat mysterious failures.

> Or maybe it has something to do with inheritance? The way
> inheritance-permissions works on ntfs is, um, let's call it
> interesting.  Maybe it needs to specify the (NP) flag to not propagate
> inheritance or something?

Sachin/Ashesh; can one of you investigate this please?

Karl; can you please provide precise details of your Windows version,
and anything unusual about your disk configuration? I know this
doesn't happen on any of the installations of Windows 7 that we use
for testing (which tend to be the MSDN builds, running on local NTFS
disks), so I wonder if there's an icacls bug in a specific build or
rev of Windows, or when used on a certain type of filesystem.

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

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

Dave Page wrote on 03.10.2011 10:11:
> Karl; can you please provide precise details of your Windows version,
> and anything unusual about your disk configuration? I know this
> doesn't happen on any of the installations of Windows 7 that we use
> for testing (which tend to be the MSDN builds, running on local NTFS
> disks), so I wonder if there's an icacls bug in a specific build or
> rev of Windows, or when used on a certain type of filesystem.
>

I have reported this as well some weeks ago.
For me this happened on a Windows7 64 bit system that is part of a domain (all current MS patches applied)
UAC is turned off, I was logged in as a local administrator (*not* a domain administrator).

I have a ProcessMonitor trace that shows the behaviour of what icacls is doing when started by the installer.
It is available here: http://www.sql-workbench.net/icacls_trace.zip

Regards
Thomas

Sorry for the delay - it's been a busy morning.

The Windows 7 system I'm using is a laptop with a standard basic Nokia
image. To the best of my knowledge there have been no OEM
modifications of any kind. It describes itself as "Windows 7
Enterprise", and says it is 32-bit. That's it.

Anything else you'd want me to check?

Karl

On Mon, Oct 3, 2011 at 4:11 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri(at)gmail(dot)com> wrote:
>>> I saw a thread where somebody saw icacls.exe being called by the
>>> one-click installer.  I'm having the same thing - the installer has
>>> been running for 45 minutes now and is basically going to have to be
>>> stopped because I'm out of time waiting for it.  Looking at process
>>> monitor, it is clear that icacls.exe is going through every file on
>>> the entire system and changing its permissions.  The process tree
>>> indicates that it is a child of the installer, and that it is running
>>> the command:
>>>
>>> icacls C:\ /grant "kawright":RX
>>>
>>> Clearly this won't do at all and should be considered a severe installer bug.
>>
>> If it does, it certainly sounds like a very bad bug.
>>
>> However, according to the documentation for icacls
>> (http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you
>> should use "/t" to get it to traverse into subdirectories, and clearly
>> it's not doing that. So I wonder why it would go across the whole
>> filesystem - might tbere be a  bug in icacls?
>
> Yes - that's how it's supposed to work (ie. *not* using /t). The
> purpose of that code is to ensure that the entire path leading up to
> the data/installation directories is readable by the users that need
> it. We've had a number of reported installation failures in the past
> caused by weirdness where read or execute permissions weren't
> available for (for example) the service account user, which caused
> somewhat mysterious failures.
>
>> Or maybe it has something to do with inheritance? The way
>> inheritance-permissions works on ntfs is, um, let's call it
>> interesting.  Maybe it needs to specify the (NP) flag to not propagate
>> inheritance or something?
>
> Sachin/Ashesh; can one of you investigate this please?
>
> Karl; can you please provide precise details of your Windows version,
> and anything unusual about your disk configuration? I know this
> doesn't happen on any of the installations of Windows 7 that we use
> for testing (which tend to be the MSDN builds, running on local NTFS
> disks), so I wonder if there's an icacls bug in a specific build or
> rev of Windows, or when used on a certain type of filesystem.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Thanks Karl. Is SP1 installed? Sachin, Ashesh - anything else you can
think of that would be useful?

On Mon, Oct 3, 2011 at 1:48 PM, Karl Wright <daddywri(at)gmail(dot)com> wrote:
> Sorry for the delay - it's been a busy morning.
>
> The Windows 7 system I'm using is a laptop with a standard basic Nokia
> image.  To the best of my knowledge there have been no OEM
> modifications of any kind.  It describes itself as "Windows 7
> Enterprise", and says it is 32-bit.  That's it.
>
> Anything else you'd want me to check?
>
> Karl
>
>
> On Mon, Oct 3, 2011 at 4:11 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri(at)gmail(dot)com> wrote:
>>>> I saw a thread where somebody saw icacls.exe being called by the
>>>> one-click installer.  I'm having the same thing - the installer has
>>>> been running for 45 minutes now and is basically going to have to be
>>>> stopped because I'm out of time waiting for it.  Looking at process
>>>> monitor, it is clear that icacls.exe is going through every file on
>>>> the entire system and changing its permissions.  The process tree
>>>> indicates that it is a child of the installer, and that it is running
>>>> the command:
>>>>
>>>> icacls C:\ /grant "kawright":RX
>>>>
>>>> Clearly this won't do at all and should be considered a severe installer bug.
>>>
>>> If it does, it certainly sounds like a very bad bug.
>>>
>>> However, according to the documentation for icacls
>>> (http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you
>>> should use "/t" to get it to traverse into subdirectories, and clearly
>>> it's not doing that. So I wonder why it would go across the whole
>>> filesystem - might tbere be a  bug in icacls?
>>
>> Yes - that's how it's supposed to work (ie. *not* using /t). The
>> purpose of that code is to ensure that the entire path leading up to
>> the data/installation directories is readable by the users that need
>> it. We've had a number of reported installation failures in the past
>> caused by weirdness where read or execute permissions weren't
>> available for (for example) the service account user, which caused
>> somewhat mysterious failures.
>>
>>> Or maybe it has something to do with inheritance? The way
>>> inheritance-permissions works on ntfs is, um, let's call it
>>> interesting.  Maybe it needs to specify the (NP) flag to not propagate
>>> inheritance or something?
>>
>> Sachin/Ashesh; can one of you investigate this please?
>>
>> Karl; can you please provide precise details of your Windows version,
>> and anything unusual about your disk configuration? I know this
>> doesn't happen on any of the installations of Windows 7 that we use
>> for testing (which tend to be the MSDN builds, running on local NTFS
>> disks), so I wonder if there's an icacls bug in a specific build or
>> rev of Windows, or when used on a certain type of filesystem.
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>

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

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

On Mon, Oct 3, 2011 at 9:42 AM, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
> Dave Page wrote on 03.10.2011 10:11:
>>
>> Karl; can you please provide precise details of your Windows version,
>> and anything unusual about your disk configuration? I know this
>> doesn't happen on any of the installations of Windows 7 that we use
>> for testing (which tend to be the MSDN builds, running on local NTFS
>> disks), so I wonder if there's an icacls bug in a specific build or
>> rev of Windows, or when used on a certain type of filesystem.
>>
>
>
> I have reported this as well some weeks ago.
> For me this happened on a Windows7 64 bit system that is part of a domain
> (all current MS patches applied)
> UAC is turned off, I was logged in as a local administrator (*not* a domain
> administrator).
>
> I have a ProcessMonitor trace that shows the behaviour of what icacls is
> doing when started by the installer.
> It is available here: http://www.sql-workbench.net/icacls_trace.zip

Thanks Thomas. That certainly doesn't look like it's doing what it was
told to :-s

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

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

I see no evidence that SP1 is installed on this machine.

Karl

On Mon, Oct 3, 2011 at 9:14 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> Thanks Karl. Is SP1 installed? Sachin, Ashesh - anything else you can
> think of that would be useful?
>
> On Mon, Oct 3, 2011 at 1:48 PM, Karl Wright <daddywri(at)gmail(dot)com> wrote:
>> Sorry for the delay - it's been a busy morning.
>>
>> The Windows 7 system I'm using is a laptop with a standard basic Nokia
>> image.  To the best of my knowledge there have been no OEM
>> modifications of any kind.  It describes itself as "Windows 7
>> Enterprise", and says it is 32-bit.  That's it.
>>
>> Anything else you'd want me to check?
>>
>> Karl
>>
>>
>> On Mon, Oct 3, 2011 at 4:11 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>> On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>> On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri(at)gmail(dot)com> wrote:
>>>>> I saw a thread where somebody saw icacls.exe being called by the
>>>>> one-click installer.  I'm having the same thing - the installer has
>>>>> been running for 45 minutes now and is basically going to have to be
>>>>> stopped because I'm out of time waiting for it.  Looking at process
>>>>> monitor, it is clear that icacls.exe is going through every file on
>>>>> the entire system and changing its permissions.  The process tree
>>>>> indicates that it is a child of the installer, and that it is running
>>>>> the command:
>>>>>
>>>>> icacls C:\ /grant "kawright":RX
>>>>>
>>>>> Clearly this won't do at all and should be considered a severe installer bug.
>>>>
>>>> If it does, it certainly sounds like a very bad bug.
>>>>
>>>> However, according to the documentation for icacls
>>>> (http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you
>>>> should use "/t" to get it to traverse into subdirectories, and clearly
>>>> it's not doing that. So I wonder why it would go across the whole
>>>> filesystem - might tbere be a  bug in icacls?
>>>
>>> Yes - that's how it's supposed to work (ie. *not* using /t). The
>>> purpose of that code is to ensure that the entire path leading up to
>>> the data/installation directories is readable by the users that need
>>> it. We've had a number of reported installation failures in the past
>>> caused by weirdness where read or execute permissions weren't
>>> available for (for example) the service account user, which caused
>>> somewhat mysterious failures.
>>>
>>>> Or maybe it has something to do with inheritance? The way
>>>> inheritance-permissions works on ntfs is, um, let's call it
>>>> interesting.  Maybe it needs to specify the (NP) flag to not propagate
>>>> inheritance or something?
>>>
>>> Sachin/Ashesh; can one of you investigate this please?
>>>
>>> Karl; can you please provide precise details of your Windows version,
>>> and anything unusual about your disk configuration? I know this
>>> doesn't happen on any of the installations of Windows 7 that we use
>>> for testing (which tend to be the MSDN builds, running on local NTFS
>>> disks), so I wonder if there's an icacls bug in a specific build or
>>> rev of Windows, or when used on a certain type of filesystem.
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

On Mon, Oct 3, 2011 at 2:15 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Mon, Oct 3, 2011 at 9:42 AM, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
>> Dave Page wrote on 03.10.2011 10:11:
>>>
>>> Karl; can you please provide precise details of your Windows version,
>>> and anything unusual about your disk configuration? I know this
>>> doesn't happen on any of the installations of Windows 7 that we use
>>> for testing (which tend to be the MSDN builds, running on local NTFS
>>> disks), so I wonder if there's an icacls bug in a specific build or
>>> rev of Windows, or when used on a certain type of filesystem.
>>>
>>
>>
>> I have reported this as well some weeks ago.
>> For me this happened on a Windows7 64 bit system that is part of a domain
>> (all current MS patches applied)
>> UAC is turned off, I was logged in as a local administrator (*not* a domain
>> administrator).
>>
>> I have a ProcessMonitor trace that shows the behaviour of what icacls is
>> doing when started by the installer.
>> It is available here: http://www.sql-workbench.net/icacls_trace.zip
>
> Thanks Thomas. That certainly doesn't look like it's doing what it was
> told to :-s

We've been looking at this today, and whilst we haven't found icacls
changing any ACLs that it shouldn't, we have no seen it reading the
ACLs of files on the entire disk. I've also found a couple of similar
reports on the net.

We updated our build system to use BitRock 7 today (for unrelated
reasons) which has new features for ACL management. We're going to
investigate replacing cacls/icacls with those features tomorrow and
will create some test builds ASAP.

Oh, the joys of supporting Windows :-)

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

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

On 10/05/2011 03:46 AM, Dave Page wrote:
> Oh, the joys of supporting Windows :-)

It's funny: for an OS with so relatively few "flavours" and versions,
the number of quirks and bizarre behaviors is quite remarkable. I guess
the text matrix isn't small, though:

Windows
XP / Vista / 7 / [8]
32-bit / 64-bit
Basic / Home / Pro or Business / Enterprise / Ultimate / Embedded
On a domain / standalone
Local admin account / non-admin account / UAC admin account
[too many different antivirus products to list]
Service packs
*endless* possible group policy configurations

... so it's not too surprising to see hard-to-reproduce weirdness
popping up.

--
Craig Ringer

On Wednesday, October 5, 2011, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> wrote:
> On 10/05/2011 03:46 AM, Dave Page wrote:
>>
>> Oh, the joys of supporting Windows :-)
>
> It's funny: for an OS with so relatively few "flavours" and versions, the
number of quirks and bizarre behaviors is quite remarkable. I guess the text
matrix isn't small, though:
>
> Windows
> XP / Vista / 7 / [8]

You forgot 2003, 2003R2, 2008 and 2008R2

> 32-bit / 64-bit
> Basic / Home / Pro or Business / Enterprise / Ultimate / Embedded

Standard, Enterprise and Datacenter for the server editions.

> On a domain / standalone
> Local admin account / non-admin account / UAC admin account

Domain admin.

> [too many different antivirus products to list]
> Service packs
> *endless* possible group policy configurations
>
> ... so it's not too surprising to see hard-to-reproduce weirdness popping
up.

That last one is one of the worst - I've seen all sorts of weird policies
from government users and large companies - they can take a *lot* of
figuring out. That's why we have 4 developers who work on the installers
(not all the time of course, but often in busy "bursts" for a few days or
more, and often in parallel, like today with 3 guys working on this issue),
along with 2 QA guys when we're building releases. It's easy to think
building and maintaining installers is easy - unfortunately, that can be
very far from the case for a product like Postgres.

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

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

Dave Page, 04.10.2011 21:46:
> We updated our build system to use BitRock 7 today (for unrelated
> reasons) which has new features for ACL management. We're going to
> investigate replacing cacls/icacls with those features tomorrow and
> will create some test builds ASAP.

If you can provide the test builds publicly, I will be happy to test them and see if that behaves differently on my system.

Regards
Thomas

On Wednesday, October 5, 2011, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
> Dave Page, 04.10.2011 21:46:
>>
>> We updated our build system to use BitRock 7 today (for unrelated
>> reasons) which has new features for ACL management. We're going to
>> investigate replacing cacls/icacls with those features tomorrow and
>> will create some test builds ASAP.
>
> If you can provide the test builds publicly, I will be happy to test them
and see if that behaves differently on my system.

Thanks, we will.

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

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

On Wed, Oct 5, 2011 at 1:24 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Wednesday, October 5, 2011, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
> > Dave Page, 04.10.2011 21:46:
>
> >>
> >> We updated our build system to use BitRock 7 today (for unrelated
> >> reasons) which has new features for ACL management. We're going to
> >> investigate replacing cacls/icacls with those features tomorrow and
> >> will create some test builds ASAP.
> >
> > If you can provide the test builds publicly, I will be happy to test them
> and see if that behaves differently on my system.
>
> Thanks, we will.
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
As someone who recently spent a couple of days fighting with icacls, I
thought I might offer some insight here. What I discovered through trial and
error and much googling is that icacls has some non-intuitive behaviors
which are not at all obvious from just reading the documentation. For
example, it behaved entirely differently if you run it against a directory
instead of a file (which may contain wildcards). The command icacls.exe
C:\mydir\ <options> (when we targeted a directory) applied <options> to
every file in C:\mydir\ and all subdirectories. icacls.exe C:\mydir\*
<options> (when we targeted a file) applied <options> to all files in C:\,
but did not apply options to files in subdirectories unless the /t switch
was provided. This behavior is not directly mentioned in the documentation,
but can be inferred from the first 2 examples, if you look at them
carefully. Also, in the syntax description, the /t switch is shown for the
icacls.exe <FileName> syntax, but not for the icacls.exe <Directory> syntax.
I never would have noticed these if I weren't looking specifically for an
explanation of the observed behavior. As far as how to use icacls to set
permisions on a directory (as opposed to the files in a directory) without
recursing to all subdirectories, I never did succeed in finding that out.

On 10/21/2011 01:43 PM, Eric McKeeth wrote:

> As far as how to use icacls to set
> permisions on a directory (as opposed to the files in a directory)
> without recursing to all subdirectories, I never did succeed in finding
> that out.

Could it depend on the presence or absence of a trailing slash? Some
"interesting" commands (I'm looking at you, rsync) are guilty of
changing behavior based on that.

--
Craig Ringer