Ah, ok. Anyway, thanks for your help.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, February 27, 2006 1:56 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Domain/workgroup move behavior in XP
My comment about process context was only relevant if you are executing this
procedure on a system thread and you created your own IRP. Other than that,
I think I’ve exhausted my suggestions.
/ted
-----Original Message-----
From: Matthew N. White [mailto:xxxxx@bitarmor.com]
Sent: Monday, February 27, 2006 11:45 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Domain/workgroup move behavior in XP
Ted,
Yes, I’m creating a new file in some cases using this method. The method
I’m using is loosely based on the probe method, and I realize that what I’m
doing was not what was originally intended. I send down my fake fileobject,
and then I own the original file object. NTFS then owns my fake file
object. I’m using the same IRP for the create with the fake FO, which has a
security context, so I think I shouldn’t have any problems with security
context being there. I’m in the original thread doing the create though, so
what do you mean by there is no user process/thread associated with it?
Matt
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, February 27, 2006 10:25 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Domain/workgroup move behavior in XP
The security field on the CREATE IRP will only apply to a newly created or
superceded object. I believe similar rules apply to the file attributes
value in CREATE as well.
You mention the use of a streamfile object in your CREATE processing. Are
you stating that you are actually creating a new or superceding an existing
file using this technique? It was never intended to be more than a “probe”
for an exisiting file. I have no idea of what the side-effects may be if you
actually create a file using this method. The problem as I imagine it would
be the lack of any security context in your CREATE call and the fact there
is no user process/thread associated with it.
/ted
-----Original Message-----
From: Matthew N. White [mailto:xxxxx@bitarmor.com]
Sent: Friday, February 24, 2006 3:25 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Domain/workgroup move behavior in XP
Thanks Ted. I checked this out, but with the file and directories in
question, the security descriptor appears to be NULL on create. Do you know
if this field would ever be used with a IRP_MJ_CREATE that is not actually
creating the file, but opening it? I would think not, but you never know.
Also, I’m using your IRP_MJ_CREATE streamfile substitution method to do the
create on an NTFS file, and using THAT fileobject (the original one my
filter owns now) for some operations in a filter. This works great for
almost everything, except the scenario I described below, that is an
EXPLORER file move across directories on a workgroup computer (MoveFile,
cmd.exe move both work fine).
My current theory is that explorer decides to “fix-up” the security on the
moved file after the move to it’s own idea of what it should be. To do
this, it first queries the parent’s security, and the security on the file
itself, and then, merging those two SDs that it just got, sets security on
the moved file. The MoveFile API itself does not do this, so I assume it’s
explorer itself deciding to do this and not an API (could be wrong about
this). Interestingly, though, office apps also appear to do this when
moving temp files around on a save.
The problem I’m having is that in this scenario, and when using the
streamfile substitution method, explorer decides not to
IRP_MJ_QUERY_SECURITY the destination parent directory of the moved file
before it IRP_MJ_QUERY_SECURITYs the moved file itself. It only queries the
moved file’s security, and then sets the security on the file. The problem
is that the security descriptor it decides to set is one with zero DACLs, so
then nothing can open the file and I’m screwed. I’m assuming this is
because the parent directory’s security descriptor (which it normally
queries) isn’t merged in. Again, this only happens in the case where I use
the streamfile sub method, so I’m assuming it’s something to do with the
fileobject not being “real” or something like that, but the only differences
I can find between the real fileobject and my substituted one are in the
object header. Anyway, wondered if you have seen anything like this when
using the streamfile sub method.
Matt
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Thursday, February 23, 2006 3:45 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Domain/workgroup move behavior in XP
Another thing to check out is the CREATE IRP itself. There is an optional
security descriptor in:
PIO_SECURITY_CONTEXT ctx = irpSp->Parameters.Create.SecurityContext
if (ctx && ctx->AccessState)
sd = ctx->AccessState->SecurityDescriptor;
HTH, /ted
-----Original Message-----
From: Alexei Jelvis [mailto:xxxxx@vmware.com]
Sent: Wednesday, February 22, 2006 6:39 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Domain/workgroup move behavior in XP
If security descriptor for the file allows inheritance from the parent then
effective security descriptor may change when the file is moved to another
directory with different permissions. And when you query security for a file
you are getting effective security descriptor back.
Alexei.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Matthew N. White
Sent: Wednesday, February 22, 2006 3:40 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Domain/workgroup move behavior in XP
Does anyone know if there is any filesystem operation on NTFS that modifies
security descriptors other than IRP_MJ_SET_SECURITY? Before the file is
moved, I read a certain security descriptor, and then right after, when
explorer does a query, the security descriptor is different. Is this
possible?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Tuesday, February 21, 2006 1:59 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Domain/workgroup move behavior in XP
Since you all are probably dying to know, MoveFile doesn’t appear to cause
this behavior…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Tuesday, February 21, 2006 9:44 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Domain/workgroup move behavior in XP
Hi all,
Can anyone explain this behavior to me?
I have an XPSP2 machine. Using explorer on an NTFS volume, I create two
directories. In one of the directories I create a new text file. Then by
right clicking I cut the file, and go into the other directory and right
click paste. This results in a move operation for the underlying file
system, NTFS in this case. This is what I expect.
The part I’m interested in is after the move completes. If the computer is
in a workgroup, I then see a IRP_MJ_QUERY_SECURITY on the parent directory,
then the moved file, and then a IRP_MJ_SET_SECURITY on the moved file. If
the computer is in a domain, I see no such security operations after the
move.
Does anyone know why this behavior is different in the workgroup/domain
cases, or where I could find this information? Also, does anyone have any
clue as to what API may be causing this behavior, if any? Would MoveFile do
this?
Thanks,
Matt
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@bitarmor.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@bitarmor.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@bitarmor.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@livevault.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@bitarmor.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@livevault.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@bitarmor.com
To unsubscribe send a blank email to xxxxx@lists.osr.com