Prev: 2GB virtual memory limit
Next: Prevent Dr Watson error handling
From: Carl Daniel [VC++ MVP] on 27 Feb 2010 13:59
I'm currently working on a problem in a production system where files are
ending up with an unexpected ACL.

The files are initially created in %TEMP% from an ASP.NET web service (i.e.
they end up in C:\windows\temp), then they're moved a couple of times into
their final resting place, both moves being done with MoveFile. The first
MoveFile executes under the identity of an impersonated user (non-admin),
while the second MoveFile executes under the Network Service identity.

The behavior I'm seeing now is that the original permissions the files
received when they were created in %TEMP% are moved along with the file -
they end up with an ACL that matches what I'd expect for a file created in
%TEMP%.

So far, all of this matches my expectations: I've always been under the
impression that MoveFile does not change the ACL on the moved file, provided
it's really moved (I.e. on the same volume) and not copied.

Here's the odd part: Prior to a couple weeks ago, this was not happening:
The moved files had the ACL that would be expected for a file originally
created in the target folder rather than the ACL from %TEMP%.

So here's the question: Is anyone aware of any recent changes - I'm
assuming something through Windows Update - that might have changed the
behavior of MoveFile with regard to permissions on the file being moved?
Absolutely nothing changed in my application: It's simply creating a file,
writing to it, closing it and moving it, as always. Another thing that
might explain it is if something's changed that would have changed the value
of %TEMP% (e.g. perhaps it was the user's temp folder in the past, but
something changed to cause it to be the system temp folder).

The ultimate solution seems obvious: Don't create the file in %TEMP%, just
create it where I want it to end up so that the permissions are what I
expect (I've explicitly set permissions on the folder - I just want the file
to inherit them). But I'm curious to understand at this point why it worked
in the first place, and what changed to make it stop working.

All affected systems are Windows Server 2003 SP2 with current patches, if
that makes any difference.

-cd


From: Alexander Grigoriev on 27 Feb 2010 22:12
I'd expect MoveFile only carries non-inherited ACL. Inherited part would not
be carried. Though if the target directory doesn't have inherited ACL,
MoveFile would probably carry full ACL. You can try these guesses easily.

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam(a)mvps.org.nospam>
wrote in message news:eqPJG89tKHA.6140(a)TK2MSFTNGP05.phx.gbl...
> I'm currently working on a problem in a production system where files are
> ending up with an unexpected ACL.
>
> The files are initially created in %TEMP% from an ASP.NET web service
> (i.e. they end up in C:\windows\temp), then they're moved a couple of
> times into their final resting place, both moves being done with MoveFile.
> The first MoveFile executes under the identity of an impersonated user
> (non-admin), while the second MoveFile executes under the Network Service
> identity.
>
> The behavior I'm seeing now is that the original permissions the files
> received when they were created in %TEMP% are moved along with the file -
> they end up with an ACL that matches what I'd expect for a file created in
> %TEMP%.
>
> So far, all of this matches my expectations: I've always been under the
> impression that MoveFile does not change the ACL on the moved file,
> provided it's really moved (I.e. on the same volume) and not copied.
>
> Here's the odd part: Prior to a couple weeks ago, this was not happening:
> The moved files had the ACL that would be expected for a file originally
> created in the target folder rather than the ACL from %TEMP%.
>
> So here's the question: Is anyone aware of any recent changes - I'm
> assuming something through Windows Update - that might have changed the
> behavior of MoveFile with regard to permissions on the file being moved?
> Absolutely nothing changed in my application: It's simply creating a
> file, writing to it, closing it and moving it, as always. Another thing
> that might explain it is if something's changed that would have changed
> the value of %TEMP% (e.g. perhaps it was the user's temp folder in the
> past, but something changed to cause it to be the system temp folder).
>
> The ultimate solution seems obvious: Don't create the file in %TEMP%,
> just create it where I want it to end up so that the permissions are what
> I expect (I've explicitly set permissions on the folder - I just want the
> file to inherit them). But I'm curious to understand at this point why it
> worked in the first place, and what changed to make it stop working.
>
> All affected systems are Windows Server 2003 SP2 with current patches, if
> that makes any difference.
>
> -cd
>
>


 | 
Pages: 1
Prev: 2GB virtual memory limit
Next: Prevent Dr Watson error handling