Hello all,
I’ve been doing some research on the best way to keep track of a SID thru
the various IRPs. I figure it out in IRP_MJ_CREATE and add it to a “table”
so I can look it up in the other IRPs like IRP_MJ_WRITE.
I read somewhere that each process that opens a file gets a different file
object and you can use this address as your “key” into your sid table.
Using an address as a key seems a little scary to me so I thought I would
ask the pros what they think.
Is using the PFILE_OBJECT that comes into IRP_MJ_CREATE the right way to
track context thru the various IRPs or is there a “safer” way?
thanks
Gene
This will work just fine. Make sure you remove the file object from the
table on CLEANUP
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gene Allen
Sent: Thursday, September 01, 2005 1:11 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] using PFILEOBJECT as a table index
Hello all,
I’ve been doing some research on the best way to keep track of a SID thru
the various IRPs. I figure it out in IRP_MJ_CREATE and add it to a “table”
so I can look it up in the other IRPs like IRP_MJ_WRITE.
I read somewhere that each process that opens a file gets a different file
object and you can use this address as your “key” into your sid table.
Using an address as a key seems a little scary to me so I thought I would
ask the pros what they think.
Is using the PFILE_OBJECT that comes into IRP_MJ_CREATE the right way to
track context thru the various IRPs or is there a “safer” way?
thanks
Gene
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@rocketdivision.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Use FileObject->FsContext as a key instead.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Gene Allen”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, September 02, 2005 12:11 AM
Subject: [ntfsd] using PFILEOBJECT as a table index
> Hello all,
>
> I’ve been doing some research on the best way to keep track of a SID thru
> the various IRPs. I figure it out in IRP_MJ_CREATE and add it to a “table”
> so I can look it up in the other IRPs like IRP_MJ_WRITE.
>
> I read somewhere that each process that opens a file gets a different file
> object and you can use this address as your “key” into your sid table.
> Using an address as a key seems a little scary to me so I thought I would
> ask the pros what they think.
>
> Is using the PFILE_OBJECT that comes into IRP_MJ_CREATE the right way to
> track context thru the various IRPs or is there a “safer” way?
>
> thanks
>
> Gene
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
I looked at that one, but according to the documentation is sounds like its
optional and could be sometimes NULL.
>“Pointer to whatever optional state a driver maintains about the file
>object; otherwise, NULL.”
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
> Use FileObject->FsContext as a key instead.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Gene Allen”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Friday, September 02, 2005 12:11 AM
> Subject: [ntfsd] using PFILEOBJECT as a table index
>
>
>> Hello all,
>>
>> I’ve been doing some research on the best way to keep track of a SID thru
>> the various IRPs. I figure it out in IRP_MJ_CREATE and add it to a
>> “table”
>> so I can look it up in the other IRPs like IRP_MJ_WRITE.
>>
>> I read somewhere that each process that opens a file gets a different
>> file
>> object and you can use this address as your “key” into your sid table.
>> Using an address as a key seems a little scary to me so I thought I would
>> ask the pros what they think.
>>
>> Is using the PFILE_OBJECT that comes into IRP_MJ_CREATE the right way to
>> track context thru the various IRPs or is there a “safer” way?
>>
>> thanks
>>
>> Gene
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
It depends on his requirements. Since he is interested in SID on a per file
object basis, he may want to track the objects and not the context.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, September 01, 2005 1:49 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] using PFILEOBJECT as a table index
Use FileObject->FsContext as a key instead.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Gene Allen”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, September 02, 2005 12:11 AM
Subject: [ntfsd] using PFILEOBJECT as a table index
> Hello all,
>
> I’ve been doing some research on the best way to keep track of a SID thru
> the various IRPs. I figure it out in IRP_MJ_CREATE and add it to a “table”
> so I can look it up in the other IRPs like IRP_MJ_WRITE.
>
> I read somewhere that each process that opens a file gets a different file
> object and you can use this address as your “key” into your sid table.
> Using an address as a key seems a little scary to me so I thought I would
> ask the pros what they think.
>
> Is using the PFILE_OBJECT that comes into IRP_MJ_CREATE the right way to
> track context thru the various IRPs or is there a “safer” way?
>
> thanks
>
> Gene
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.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@rocketdivision.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> Use FileObject->FsContext as a key instead.
Interesting thing is that FileSpy uses the FileObject itself
as the hash value. It seemed strange to me when I first
saw it.
L.
The FileObject address works well as a “stream instance” key. The first
inclination is to use it directly (hand it to the app, have the app hand
it back) but then you realize that the risk in so doing is that the
application might give back a stale file object, or a malicious
application might hand back bogus data. As Jamey pointed out, there
are times when you want to deal with the open instance (“stream
instance”).
And since we’re cataloging tracking techniques, here’s what I generally
suggest using right now:
-
Per stream is done with FsContext (or SectionObjectPointers if you are
feeling like being “different” that day). Those are unique per stream
on NTFS, but don’t tie two different streams of the same file together.
Hence the NTFS-oriented terminology of calling the FsContext the “Stream
Control Block (SCB)”.
-
Per stream instance is done with FileObject (avoiding the file NAME as
much, and whenever possible). While the FsContext2 field is generally
created on a per-open-instance basis, there’s no requirement that it
even exist or be unique (this field’s structure is far less well-defined
than the FsContext field).
-
Per file is done using the FileInternalInformation (“file ID”), but is
only unique per volume (e.g., track in a per-volume table). Note that
this unfortunately doesn’t work with MRXSMB as a general rule, since the
file IDs are locally generated on the client, not the real file IDs from
the server (at least last I checked, but the redirector folk can, and
do, change things over time). In our own DMK (which uses its own
structured storage mechanism) we actually decided to embed a GUID in the
file so that we can definitively map this information (AND it solves the
ambiguous naming problem for RDR - where two distinct path names map to
the exact same file).
Most people don’t seem to have too much trouble tracking per-volume
state but it is generally tied to a device object.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Friday, September 02, 2005 1:49 AM
To: ntfsd redirect
Subject: Re: [ntfsd] using PFILEOBJECT as a table index
Use FileObject->FsContext as a key instead.
Interesting thing is that FileSpy uses the FileObject itself
as the hash value. It seemed strange to me when I first
saw it.
L.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
It is never NULL for a filesystem which supports cache and memory mapped
files.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Gene Allen”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, September 02, 2005 1:32 AM
Subject: Re:[ntfsd] using PFILEOBJECT as a table index
> I looked at that one, but according to the documentation is sounds like its
> optional and could be sometimes NULL.
> >>“Pointer to whatever optional state a driver maintains about the file
> >>object; otherwise, NULL.”
>
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntfsd…
> > Use FileObject->FsContext as a key instead.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> > ----- Original Message -----
> > From: “Gene Allen”
> > Newsgroups: ntfsd
> > To: “Windows File Systems Devs Interest List”
> > Sent: Friday, September 02, 2005 12:11 AM
> > Subject: [ntfsd] using PFILEOBJECT as a table index
> >
> >
> >> Hello all,
> >>
> >> I’ve been doing some research on the best way to keep track of a SID thru
> >> the various IRPs. I figure it out in IRP_MJ_CREATE and add it to a
> >> “table”
> >> so I can look it up in the other IRPs like IRP_MJ_WRITE.
> >>
> >> I read somewhere that each process that opens a file gets a different
> >> file
> >> object and you can use this address as your “key” into your sid table.
> >> Using an address as a key seems a little scary to me so I thought I would
> >> ask the pros what they think.
> >>
> >> Is using the PFILE_OBJECT that comes into IRP_MJ_CREATE the right way to
> >> track context thru the various IRPs or is there a “safer” way?
> >>
> >> thanks
> >>
> >> Gene
> >>
> >>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as: xxxxx@storagecraft.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@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com