Thread: 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@gmail.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@hagander.net> wrote: > On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri@gmail.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@pgadmin.org> wrote: > On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander <magnus@hagander.net> wrote: >> On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri@gmail.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@gmail.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@pgadmin.org> wrote: >> On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander <magnus@hagander.net> wrote: >>> On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri@gmail.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@gmx.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@pgadmin.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@gmail.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@pgadmin.org> wrote: >>> On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander <magnus@hagander.net> wrote: >>>> On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri@gmail.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@pgadmin.org> wrote: > On Mon, Oct 3, 2011 at 9:42 AM, Thomas Kellerer <spam_eater@gmx.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@ringerc.id.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
On Wednesday, October 5, 2011, Thomas Kellerer <spam_eater@gmx.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@pgadmin.org> wrote:
On Wednesday, October 5, 2011, Thomas Kellerer <spam_eater@gmx.net> wrote:
> Dave Page, 04.10.2011 21:46:> If you can provide the test builds publicly, I will be happy to test them and see if that behaves differently on my system.
>>
>> 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.
>
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