Inline (file under FAQ as answer to question “When posting a create in a
filesystem filter, should I store and impersonate the security context
of the original thread?”)
Alexei Jelvis wrote:
>anyway, i am using SeImpersonateClientEx to make the system thread created
>to have the same credentials as the original thread so that the lower file
>system can correctly check the access permission. is this correct?
>
I don’t think you need to impersonate the system thread - IRP_MJ_CREATE has
a pointer to context information that is supposed to be used by file system
instead of security context of the current process.
He actually does need to. There is one corner case (which I believe
Microsoft should classify as a bug) where FastFat performs a privilege
check against the current thread’s token while processing a create. (The
offending code is in FatCheckSystemSecurityAccess).
–
Right, security context is stored in request. But FastFat, for example, uses
current thread security context (SeSinglePrivilegeCheck in
FatCheckSystemSecurityAccess routine). So, you’d better impersonate your
system thread as you don’t know underlying FSD behaviour. This operation is
not expensive compared to new thread creation.
-htfv
----- Original Message -----
From: “Alexei Jelvis”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Tuesday, July 29, 2003 7:04 AM
Subject: [ntfsd] Re: creating system thread for create
>
> > anyway, i am using SeImpersonateClientEx to make the system thread
created
> > to have the same credentials as the original thread so that the lower
file
> > system can correctly check the access permission. is this correct?
> >
>
> I don’t think you need to impersonate the system thread - IRP_MJ_CREATE
has
> a pointer to context information that is supposed to be used by file
system
> instead of security context of the current process.
>
> > also, is there a rough estimate of how much stack space ntfs needs so
that
> i
> > can know when to create the system thread?
> >
>
> I also would like to know this. It afraid the only way to estimate this is
> try & error approach. If there are some file system filters below your
> filter or some storage filters this value may vary significantly.
>
> > Ampsi
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
(Now THAT’s an FAQ entry we can make quickly and easily… thanks Nick!)
“Nick Ryan” wrote in message news:xxxxx@ntfsd…
>
> Inline (file under FAQ as answer to question “When posting a create in a
> filesystem filter, should I store and impersonate the security context
> of the original thread?”)
>
> Alexei Jelvis wrote:
>
> >>anyway, i am using SeImpersonateClientEx to make the system thread
created
> >>to have the same credentials as the original thread so that the lower
file
> >>system can correctly check the access permission. is this correct?
> >>
> >
> >
> > I don’t think you need to impersonate the system thread - IRP_MJ_CREATE
has
> > a pointer to context information that is supposed to be used by file
system
> > instead of security context of the current process.
> >
>
> He actually does need to. There is one corner case (which I believe
> Microsoft should classify as a bug) where FastFat performs a privilege
> check against the current thread’s token while processing a create. (The
> offending code is in FatCheckSystemSecurityAccess).
>
> –
> - Nick Ryan (MVP for DDK)
>
>
>
>
I remember one rule from Tony’s File Systems class. Do not change switch
threads as the file systems expect to be in the user’s context.
“Peter Viscarola” wrote in message news:xxxxx@ntfsd…
>
> (Now THAT’s an FAQ entry we can make quickly and easily… thanks Nick!)
>
> “Nick Ryan” wrote in message news:xxxxx@ntfsd…
> >
> > Inline (file under FAQ as answer to question “When posting a create in a
> > filesystem filter, should I store and impersonate the security context
> > of the original thread?”)
> >
> > Alexei Jelvis wrote:
> >
> > >>anyway, i am using SeImpersonateClientEx to make the system thread
> created
> > >>to have the same credentials as the original thread so that the lower
> file
> > >>system can correctly check the access permission. is this correct?
> > >>
> > >
> > >
> > > I don’t think you need to impersonate the system thread -
IRP_MJ_CREATE
> has
> > > a pointer to context information that is supposed to be used by file
> system
> > > instead of security context of the current process.
> > >
> >
> > He actually does need to. There is one corner case (which I believe
> > Microsoft should classify as a bug) where FastFat performs a privilege
> > check against the current thread’s token while processing a create. (The
> > offending code is in FatCheckSystemSecurityAccess).
> >
> > –
> > - Nick Ryan (MVP for DDK)
> >
> >
> >
> >
>
>
>
>
Yes, they rely on Irp->UserBuffer, among all other things. At least the
cached read/write paths of the FSD must be called from the original thread.
Max
----- Original Message -----
From: “David J. Craig”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Tuesday, July 29, 2003 8:44 PM
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
> I remember one rule from Tony’s File Systems class. Do not change switch
> threads as the file systems expect to be in the user’s context.
>
> “Peter Viscarola” wrote in message news:xxxxx@ntfsd…
> >
> > (Now THAT’s an FAQ entry we can make quickly and easily… thanks Nick!)
> >
> > “Nick Ryan” wrote in message news:xxxxx@ntfsd…
> > >
> > > Inline (file under FAQ as answer to question “When posting a create in a
> > > filesystem filter, should I store and impersonate the security context
> > > of the original thread?”)
> > >
> > > Alexei Jelvis wrote:
> > >
> > > >>anyway, i am using SeImpersonateClientEx to make the system thread
> > created
> > > >>to have the same credentials as the original thread so that the lower
> > file
> > > >>system can correctly check the access permission. is this correct?
> > > >>
> > > >
> > > >
> > > > I don’t think you need to impersonate the system thread -
> IRP_MJ_CREATE
> > has
> > > > a pointer to context information that is supposed to be used by file
> > system
> > > > instead of security context of the current process.
> > > >
> > >
> > > He actually does need to. There is one corner case (which I believe
> > > Microsoft should classify as a bug) where FastFat performs a privilege
> > > check against the current thread’s token while processing a create. (The
> > > offending code is in FatCheckSystemSecurityAccess).
> > >
> > > –
> > > - Nick Ryan (MVP for DDK)
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Actually the original question was about security context on Create path.
Other IRP you can post to another thread if you allocate MDL that describes
user buffer. Cached Read/Write uses system buffer from MDL if IRP has an
MDL. There are some exceptions - FSCTL defined as METHOD_NIETHER has input
data in Type3InputBuffer - there is no easy way to make it available in the
system process.
Alexei.
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
>
> Yes, they rely on Irp->UserBuffer, among all other things. At least
the
> cached read/write paths of the FSD must be called from the original
thread.
>
> Max
>
> ----- Original Message -----
> From: “David J. Craig”
> Newsgroups: ntfsd
> To: “File Systems Developers”
> Sent: Tuesday, July 29, 2003 8:44 PM
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
>
> > I remember one rule from Tony’s File Systems class. Do not change
switch
> > threads as the file systems expect to be in the user’s context.
> >
> > “Peter Viscarola” wrote in message news:xxxxx@ntfsd…
> > >
> > > (Now THAT’s an FAQ entry we can make quickly and easily… thanks
Nick!)
> > >
> > > “Nick Ryan” wrote in message news:xxxxx@ntfsd…
> > > >
> > > > Inline (file under FAQ as answer to question “When posting a create
in a
> > > > filesystem filter, should I store and impersonate the security
context
> > > > of the original thread?”)
> > > >
> > > > Alexei Jelvis wrote:
> > > >
> > > > >>anyway, i am using SeImpersonateClientEx to make the system thread
> > > created
> > > > >>to have the same credentials as the original thread so that the
lower
> > > file
> > > > >>system can correctly check the access permission. is this correct?
> > > > >>
> > > > >
> > > > >
> > > > > I don’t think you need to impersonate the system thread -
> > IRP_MJ_CREATE
> > > has
> > > > > a pointer to context information that is supposed to be used by
file
> > > system
> > > > > instead of security context of the current process.
> > > > >
> > > >
> > > > He actually does need to. There is one corner case (which I believe
> > > > Microsoft should classify as a bug) where FastFat performs a
privilege
> > > > check against the current thread’s token while processing a create.
(The
> > > > offending code is in FatCheckSystemSecurityAccess).
> > > >
> > > > –
> > > > - Nick Ryan (MVP for DDK)
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
This particular code (FatCheckSystemSecurityAccess) is quite starnge. First
of all why bother to check for the ACCESS_SYSTEM_SECURITY flag in desired
access if caller has no way to take advantage of it - FAT doesn’t support
security. Second it forces privilege check as if caller is from user mode
which doesn’t follow convention that there is no security check if create
request is originated from kernel.
Alexei.
“Nick Ryan” wrote in message news:xxxxx@ntfsd…
>
> Inline (file under FAQ as answer to question “When posting a create in a
> filesystem filter, should I store and impersonate the security context
> of the original thread?”)
>
> Alexei Jelvis wrote:
>
> >>anyway, i am using SeImpersonateClientEx to make the system thread
created
> >>to have the same credentials as the original thread so that the lower
file
> >>system can correctly check the access permission. is this correct?
> >>
> >
> >
> > I don’t think you need to impersonate the system thread - IRP_MJ_CREATE
has
> > a pointer to context information that is supposed to be used by file
system
> > instead of security context of the current process.
> >
>
> He actually does need to. There is one corner case (which I believe
> Microsoft should classify as a bug) where FastFat performs a privilege
> check against the current thread’s token while processing a create. (The
> offending code is in FatCheckSystemSecurityAccess).
>
> –
> - Nick Ryan (MVP for DDK)
>
>
>
>
Since create is always called at PASSIVE_LEVEL, why would anyone EVER
need to post the request to a system thread?
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Tuesday, July 29, 2003 4:56 PM
To: File Systems Developers
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
Actually the original question was about security context on Create
path.
Other IRP you can post to another thread if you allocate MDL that
describes
user buffer. Cached Read/Write uses system buffer from MDL if IRP has an
MDL. There are some exceptions - FSCTL defined as METHOD_NIETHER has
input
data in Type3InputBuffer - there is no easy way to make it available in
the
system process.
Alexei.
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
>
> Yes, they rely on Irp->UserBuffer, among all other things. At
least
the
> cached read/write paths of the FSD must be called from the original
thread.
>
> Max
>
> ----- Original Message -----
> From: “David J. Craig”
> Newsgroups: ntfsd
> To: “File Systems Developers”
> Sent: Tuesday, July 29, 2003 8:44 PM
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
>
> > I remember one rule from Tony’s File Systems class. Do not change
switch
> > threads as the file systems expect to be in the user’s context.
> >
> > “Peter Viscarola” wrote in message
news:xxxxx@ntfsd…
> > >
> > > (Now THAT’s an FAQ entry we can make quickly and easily… thanks
Nick!)
> > >
> > > “Nick Ryan” wrote in message news:xxxxx@ntfsd…
> > > >
> > > > Inline (file under FAQ as answer to question “When posting a
create
in a
> > > > filesystem filter, should I store and impersonate the security
context
> > > > of the original thread?”)
> > > >
> > > > Alexei Jelvis wrote:
> > > >
> > > > >>anyway, i am using SeImpersonateClientEx to make the system
thread
> > > created
> > > > >>to have the same credentials as the original thread so that
the
lower
> > > file
> > > > >>system can correctly check the access permission. is this
correct?
> > > > >>
> > > > >
> > > > >
> > > > > I don’t think you need to impersonate the system thread -
> > IRP_MJ_CREATE
> > > has
> > > > > a pointer to context information that is supposed to be used
by
file
> > > system
> > > > > instead of security context of the current process.
> > > > >
> > > >
> > > > He actually does need to. There is one corner case (which I
believe
> > > > Microsoft should classify as a bug) where FastFat performs a
privilege
> > > > check against the current thread’s token while processing a
create.
(The
> > > > offending code is in FatCheckSystemSecurityAccess).
> > > >
> > > > –
> > > > - Nick Ryan (MVP for DDK)
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
—
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
i see. thanks.
Ampsi
----- Original Message -----
From: “Alexey Logachyov”
To: “File Systems Developers”
Sent: Tuesday, July 29, 2003 16:32
Subject: [ntfsd] Re: creating system thread for create
Right, security context is stored in request. But FastFat, for example, uses
current thread security context (SeSinglePrivilegeCheck in
FatCheckSystemSecurityAccess routine). So, you’d better impersonate your
system thread as you don’t know underlying FSD behaviour. This operation is
not expensive compared to new thread creation.
-htfv
----- Original Message -----
From: “Alexei Jelvis”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Tuesday, July 29, 2003 7:04 AM
Subject: [ntfsd] Re: creating system thread for create
>
> > anyway, i am using SeImpersonateClientEx to make the system thread
created
> > to have the same credentials as the original thread so that the lower
file
> > system can correctly check the access permission. is this correct?
> >
>
> I don’t think you need to impersonate the system thread - IRP_MJ_CREATE
has
> a pointer to context information that is supposed to be used by file
system
> instead of security context of the current process.
>
> > also, is there a rough estimate of how much stack space ntfs needs so
that
> i
> > can know when to create the system thread?
> >
>
> I also would like to know this. It afraid the only way to estimate this is
> try & error approach. If there are some file system filters below your
> filter or some storage filters this value may vary significantly.
>
> > Ampsi
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
—
You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
To unsubscribe send a blank email to xxxxx@lists.osr.com
bingo! my latest experience with NAV and NIS 2003 is NTFS will complain of
low stack space even when the stack still has more than 6000 bytes when it
entered my filter.
Ampsi
----- Original Message -----
From: “Nick Ryan”
To: “File Systems Developers”
Sent: Wednesday, July 30, 2003 14:30
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
Low on stack space?
Jamey Kirby wrote:
> Since create is always called at PASSIVE_LEVEL, why would anyone EVER
> need to post the request to a system thread?
>
> Jamey
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
> Sent: Tuesday, July 29, 2003 4:56 PM
> To: File Systems Developers
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
> Actually the original question was about security context on Create
> path.
> Other IRP you can post to another thread if you allocate MDL that
> describes
> user buffer. Cached Read/Write uses system buffer from MDL if IRP has an
> MDL. There are some exceptions - FSCTL defined as METHOD_NIETHER has
> input
> data in Type3InputBuffer - there is no easy way to make it available in
> the
> system process.
>
> Alexei.
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntfsd…
>
>> Yes, they rely on Irp->UserBuffer, among all other things. At
>
> least
> the
>
>>cached read/write paths of the FSD must be called from the original
>
> thread.
>
>> Max
>>
>>----- Original Message -----
>>From: “David J. Craig”
>>Newsgroups: ntfsd
>>To: “File Systems Developers”
>>Sent: Tuesday, July 29, 2003 8:44 PM
>>Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>>
>>
>>
>>>I remember one rule from Tony’s File Systems class. Do not change
>
> switch
>
>>>threads as the file systems expect to be in the user’s context.
>>>
>>>“Peter Viscarola” wrote in message
>
> news:xxxxx@ntfsd…
>
>>>>(Now THAT’s an FAQ entry we can make quickly and easily… thanks
>
> Nick!)
>
>>>>“Nick Ryan” wrote in message news:xxxxx@ntfsd…
>>>>
>>>>>Inline (file under FAQ as answer to question “When posting a
>
> create
> in a
>
>>>>>filesystem filter, should I store and impersonate the security
>
> context
>
>>>>>of the original thread?”)
>>>>>
>>>>>Alexei Jelvis wrote:
>>>>>
>>>>>
>>>>>>>anyway, i am using SeImpersonateClientEx to make the system
>
> thread
>
>>>>created
>>>>
>>>>>>>to have the same credentials as the original thread so that
>
> the
> lower
>
>>>>file
>>>>
>>>>>>>system can correctly check the access permission. is this
>
> correct?
>
>>>>>>
>>>>>>I don’t think you need to impersonate the system thread -
>>>
>>>IRP_MJ_CREATE
>>>
>>>>has
>>>>
>>>>>>a pointer to context information that is supposed to be used
>
> by
> file
>
>>>>system
>>>>
>>>>>>instead of security context of the current process.
>>>>>>
>>>>>
>>>>>He actually does need to. There is one corner case (which I
>
> believe
>
>>>>>Microsoft should classify as a bug) where FastFat performs a
>
> privilege
>
>>>>>check against the current thread’s token while processing a
>
> create.
> (The
>
>>>>>offending code is in FatCheckSystemSecurityAccess).
>>>>>
>>>>>–
>>>>>- Nick Ryan (MVP for DDK)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>—
>>>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Nick Ryan (MVP for DDK)
—
You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
To unsubscribe send a blank email to xxxxx@lists.osr.com
How much is left when you pass the request along in your filter?
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Wednesday, July 30, 2003 12:30 AM
To: File Systems Developers
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
bingo! my latest experience with NAV and NIS 2003 is NTFS will complain
of
low stack space even when the stack still has more than 6000 bytes when
it
entered my filter.
Ampsi
----- Original Message -----
From: “Nick Ryan”
To: “File Systems Developers”
Sent: Wednesday, July 30, 2003 14:30
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
Low on stack space?
Jamey Kirby wrote:
> Since create is always called at PASSIVE_LEVEL, why would anyone EVER
> need to post the request to a system thread?
>
> Jamey
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
> Sent: Tuesday, July 29, 2003 4:56 PM
> To: File Systems Developers
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
> Actually the original question was about security context on Create
> path.
> Other IRP you can post to another thread if you allocate MDL that
> describes
> user buffer. Cached Read/Write uses system buffer from MDL if IRP has
an
> MDL. There are some exceptions - FSCTL defined as METHOD_NIETHER has
> input
> data in Type3InputBuffer - there is no easy way to make it available
in
> the
> system process.
>
> Alexei.
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntfsd…
>
>> Yes, they rely on Irp->UserBuffer, among all other things. At
>
> least
> the
>
>>cached read/write paths of the FSD must be called from the original
>
> thread.
>
>> Max
>>
>>----- Original Message -----
>>From: “David J. Craig”
>>Newsgroups: ntfsd
>>To: “File Systems Developers”
>>Sent: Tuesday, July 29, 2003 8:44 PM
>>Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>>
>>
>>
>>>I remember one rule from Tony’s File Systems class. Do not change
>
> switch
>
>>>threads as the file systems expect to be in the user’s context.
>>>
>>>“Peter Viscarola” wrote in message
>
> news:xxxxx@ntfsd…
>
>>>>(Now THAT’s an FAQ entry we can make quickly and easily… thanks
>
> Nick!)
>
>>>>“Nick Ryan” wrote in message news:xxxxx@ntfsd…
>>>>
>>>>>Inline (file under FAQ as answer to question “When posting a
>
> create
> in a
>
>>>>>filesystem filter, should I store and impersonate the security
>
> context
>
>>>>>of the original thread?”)
>>>>>
>>>>>Alexei Jelvis wrote:
>>>>>
>>>>>
>>>>>>>anyway, i am using SeImpersonateClientEx to make the system
>
> thread
>
>>>>created
>>>>
>>>>>>>to have the same credentials as the original thread so that
>
> the
> lower
>
>>>>file
>>>>
>>>>>>>system can correctly check the access permission. is this
>
> correct?
>
>>>>>>
>>>>>>I don’t think you need to impersonate the system thread -
>>>
>>>IRP_MJ_CREATE
>>>
>>>>has
>>>>
>>>>>>a pointer to context information that is supposed to be used
>
> by
> file
>
>>>>system
>>>>
>>>>>>instead of security context of the current process.
>>>>>>
>>>>>
>>>>>He actually does need to. There is one corner case (which I
>
> believe
>
>>>>>Microsoft should classify as a bug) where FastFat performs a
>
> privilege
>
>>>>>check against the current thread’s token while processing a
>
> create.
> (The
>
>>>>>offending code is in FatCheckSystemSecurityAccess).
>>>>>
>>>>>–
>>>>>- Nick Ryan (MVP for DDK)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>—
>>>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Nick Ryan (MVP for DDK)
—
You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Not if you do what FatLockUserBuffer does.
Yes, they rely on Irp->UserBuffer, among all other things. At least the
cached read/write paths of the FSD must be called from the original thread.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
i did not really check the size left, but i think when i hit this situation,
it is probably the create coming into my shadow device. i check and spawn a
thread for the requests to my filter devces but did not do the check for
requests to my shadow devices. so when i always spawn a thread when calling
my shadow devices, i don’t seem to see NTFS complaining.
btw, there are various ways to use system threads, which is the most
appropriate for create? there’s the work item way of using the system’s own
set of system threads, there’s PsCreateSystemThread and there’s
FsRtlPostStackOverflow. according to the documentation, FSFDs are not to use
FsRtlPostStackOverflow and should use work items instead.
Ampsi
----- Original Message -----
From: “Jamey Kirby”
To: “File Systems Developers”
Sent: Wednesday, July 30, 2003 15:55
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
How much is left when you pass the request along in your filter?
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Wednesday, July 30, 2003 12:30 AM
To: File Systems Developers
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
bingo! my latest experience with NAV and NIS 2003 is NTFS will complain
of
low stack space even when the stack still has more than 6000 bytes when
it
entered my filter.
Ampsi
----- Original Message -----
From: “Nick Ryan”
To: “File Systems Developers”
Sent: Wednesday, July 30, 2003 14:30
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
Low on stack space?
Jamey Kirby wrote:
> Since create is always called at PASSIVE_LEVEL, why would anyone EVER
> need to post the request to a system thread?
>
> Jamey
>
Posting creates is just a bad idea, period. You’re going to have no end
of grief with anti-virus products that recursively open the file while
filtering a create (or cleanup, for that matter).
Ampsi wrote:
i did not really check the size left, but i think when i hit this situation,
it is probably the create coming into my shadow device. i check and spawn a
thread for the requests to my filter devces but did not do the check for
requests to my shadow devices. so when i always spawn a thread when calling
my shadow devices, i don’t seem to see NTFS complaining.
btw, there are various ways to use system threads, which is the most
appropriate for create? there’s the work item way of using the system’s own
set of system threads, there’s PsCreateSystemThread and there’s
FsRtlPostStackOverflow. according to the documentation, FSFDs are not to use
FsRtlPostStackOverflow and should use work items instead.
Ampsi
----- Original Message -----
From: “Jamey Kirby”
> To: “File Systems Developers”
> Sent: Wednesday, July 30, 2003 15:55
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
>
> How much is left when you pass the request along in your filter?
>
> Jamey
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
> Sent: Wednesday, July 30, 2003 12:30 AM
> To: File Systems Developers
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
> bingo! my latest experience with NAV and NIS 2003 is NTFS will complain
> of
> low stack space even when the stack still has more than 6000 bytes when
> it
> entered my filter.
>
> Ampsi
>
> ----- Original Message -----
> From: “Nick Ryan”
> To: “File Systems Developers”
> Sent: Wednesday, July 30, 2003 14:30
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
>
> Low on stack space?
>
> Jamey Kirby wrote:
>
>
>>Since create is always called at PASSIVE_LEVEL, why would anyone EVER
>>need to post the request to a system thread?
>>
>>Jamey
>>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Nick Ryan (MVP for DDK)
does posting create imply a new create? from what i intepret, in the
message, it seems to say so…
what i did is if the stack space is low, i will create a thread to continue
the rest of the code, waiting in the original thread. when the created
thread has finished, it will trigger the original thread to return. is this
posting a create?
Ampsi
----- Original Message -----
From: “Nick Ryan”
To: “File Systems Developers”
Sent: Friday, August 01, 2003 10:22
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
Posting creates is just a bad idea, period. You’re going to have no end
of grief with anti-virus products that recursively open the file while
filtering a create (or cleanup, for that matter).
Ampsi wrote:
> i did not really check the size left, but i think when i hit this
situation,
> it is probably the create coming into my shadow device. i check and spawn
a
> thread for the requests to my filter devces but did not do the check for
> requests to my shadow devices. so when i always spawn a thread when
calling
> my shadow devices, i don’t seem to see NTFS complaining.
>
> btw, there are various ways to use system threads, which is the most
> appropriate for create? there’s the work item way of using the system’s
own
> set of system threads, there’s PsCreateSystemThread and there’s
> FsRtlPostStackOverflow. according to the documentation, FSFDs are not to
use
> FsRtlPostStackOverflow and should use work items instead.
>
> Ampsi
>
> ----- Original Message -----
> From: “Jamey Kirby”
> To: “File Systems Developers”
> Sent: Wednesday, July 30, 2003 15:55
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
>
> How much is left when you pass the request along in your filter?
>
> Jamey
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
> Sent: Wednesday, July 30, 2003 12:30 AM
> To: File Systems Developers
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
> bingo! my latest experience with NAV and NIS 2003 is NTFS will complain
> of
> low stack space even when the stack still has more than 6000 bytes when
> it
> entered my filter.
>
> Ampsi
>
> ----- Original Message -----
> From: “Nick Ryan”
> To: “File Systems Developers”
> Sent: Wednesday, July 30, 2003 14:30
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
>
> Low on stack space?
>
> Jamey Kirby wrote:
>
>
>>Since create is always called at PASSIVE_LEVEL, why would anyone EVER
>>need to post the request to a system thread?
>>
>>Jamey
>>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Nick Ryan (MVP for DDK)
—
You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
To unsubscribe send a blank email to xxxxx@lists.osr.com
You should create your own thread using PsCreateSystemThread(). Worker
threads are a limited resource.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Thursday, July 31, 2003 6:57 PM
To: File Systems Developers
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
i did not really check the size left, but i think when i hit this
situation,
it is probably the create coming into my shadow device. i check and
spawn a
thread for the requests to my filter devces but did not do the check for
requests to my shadow devices. so when i always spawn a thread when
calling
my shadow devices, i don’t seem to see NTFS complaining.
btw, there are various ways to use system threads, which is the most
appropriate for create? there’s the work item way of using the system’s
own
set of system threads, there’s PsCreateSystemThread and there’s
FsRtlPostStackOverflow. according to the documentation, FSFDs are not to
use
FsRtlPostStackOverflow and should use work items instead.
Ampsi
----- Original Message -----
From: “Jamey Kirby”
To: “File Systems Developers”
Sent: Wednesday, July 30, 2003 15:55
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
How much is left when you pass the request along in your filter?
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Wednesday, July 30, 2003 12:30 AM
To: File Systems Developers
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
bingo! my latest experience with NAV and NIS 2003 is NTFS will complain
of
low stack space even when the stack still has more than 6000 bytes when
it
entered my filter.
Ampsi
----- Original Message -----
From: “Nick Ryan”
To: “File Systems Developers”
Sent: Wednesday, July 30, 2003 14:30
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
Low on stack space?
Jamey Kirby wrote:
> Since create is always called at PASSIVE_LEVEL, why would anyone EVER
> need to post the request to a system thread?
>
> Jamey
>
—
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
If you create a new thread dynamically for each create that you post,
you should be OK. My concern was that you’d have a limited number of
pre-created threads that would force serialization of creates (which may
deadlock with AV products that recursively call ZwCreate/OpenFile on opens).
Ampsi wrote:
does posting create imply a new create? from what i intepret, in the
message, it seems to say so…
what i did is if the stack space is low, i will create a thread to continue
the rest of the code, waiting in the original thread. when the created
thread has finished, it will trigger the original thread to return. is this
posting a create?
Ampsi
----- Original Message -----
From: “Nick Ryan”
> To: “File Systems Developers”
> Sent: Friday, August 01, 2003 10:22
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
>
> Posting creates is just a bad idea, period. You’re going to have no end
> of grief with anti-virus products that recursively open the file while
> filtering a create (or cleanup, for that matter).
>
> Ampsi wrote:
>
>
>>i did not really check the size left, but i think when i hit this
>
> situation,
>
>>it is probably the create coming into my shadow device. i check and spawn
>
> a
>
>>thread for the requests to my filter devces but did not do the check for
>>requests to my shadow devices. so when i always spawn a thread when
>
> calling
>
>>my shadow devices, i don’t seem to see NTFS complaining.
>>
>>btw, there are various ways to use system threads, which is the most
>>appropriate for create? there’s the work item way of using the system’s
>
> own
>
>>set of system threads, there’s PsCreateSystemThread and there’s
>>FsRtlPostStackOverflow. according to the documentation, FSFDs are not to
>
> use
>
>>FsRtlPostStackOverflow and should use work items instead.
>>
>>Ampsi
>>
>>----- Original Message -----
>>From: “Jamey Kirby”
>>To: “File Systems Developers”
>>Sent: Wednesday, July 30, 2003 15:55
>>Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>>
>>
>>How much is left when you pass the request along in your filter?
>>
>>Jamey
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
>>Sent: Wednesday, July 30, 2003 12:30 AM
>>To: File Systems Developers
>>Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>>
>>bingo! my latest experience with NAV and NIS 2003 is NTFS will complain
>>of
>>low stack space even when the stack still has more than 6000 bytes when
>>it
>>entered my filter.
>>
>>Ampsi
>>
>>----- Original Message -----
>>From: “Nick Ryan”
>>To: “File Systems Developers”
>>Sent: Wednesday, July 30, 2003 14:30
>>Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>>
>>
>>Low on stack space?
>>
>>Jamey Kirby wrote:
>>
>>
>>
>>>Since create is always called at PASSIVE_LEVEL, why would anyone EVER
>>>need to post the request to a system thread?
>>>
>>>Jamey
>>>
>>
>>
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@nryan.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
> –
> - Nick Ryan (MVP for DDK)
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Nick Ryan (MVP for DDK)
i see. thanks!
Ampsi
----- Original Message -----
From: “Nick Ryan”
To: “File Systems Developers”
Sent: Saturday, August 02, 2003 01:13
Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
If you create a new thread dynamically for each create that you post,
you should be OK. My concern was that you’d have a limited number of
pre-created threads that would force serialization of creates (which may
deadlock with AV products that recursively call ZwCreate/OpenFile on opens).
Ampsi wrote:
> does posting create imply a new create? from what i intepret, in the
> message, it seems to say so…
>
> what i did is if the stack space is low, i will create a thread to
continue
> the rest of the code, waiting in the original thread. when the created
> thread has finished, it will trigger the original thread to return. is
this
> posting a create?
>
> Ampsi
>
> ----- Original Message -----
> From: “Nick Ryan”
> To: “File Systems Developers”
> Sent: Friday, August 01, 2003 10:22
> Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>
>
> Posting creates is just a bad idea, period. You’re going to have no end
> of grief with anti-virus products that recursively open the file while
> filtering a create (or cleanup, for that matter).
>
> Ampsi wrote:
>
>
>>i did not really check the size left, but i think when i hit this
>
> situation,
>
>>it is probably the create coming into my shadow device. i check and spawn
>
> a
>
>>thread for the requests to my filter devces but did not do the check for
>>requests to my shadow devices. so when i always spawn a thread when
>
> calling
>
>>my shadow devices, i don’t seem to see NTFS complaining.
>>
>>btw, there are various ways to use system threads, which is the most
>>appropriate for create? there’s the work item way of using the system’s
>
> own
>
>>set of system threads, there’s PsCreateSystemThread and there’s
>>FsRtlPostStackOverflow. according to the documentation, FSFDs are not to
>
> use
>
>>FsRtlPostStackOverflow and should use work items instead.
>>
>>Ampsi
>>
>>----- Original Message -----
>>From: “Jamey Kirby”
>>To: “File Systems Developers”
>>Sent: Wednesday, July 30, 2003 15:55
>>Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>>
>>
>>How much is left when you pass the request along in your filter?
>>
>>Jamey
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
>>Sent: Wednesday, July 30, 2003 12:30 AM
>>To: File Systems Developers
>>Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>>
>>bingo! my latest experience with NAV and NIS 2003 is NTFS will complain
>>of
>>low stack space even when the stack still has more than 6000 bytes when
>>it
>>entered my filter.
>>
>>Ampsi
>>
>>----- Original Message -----
>>From: “Nick Ryan”
>>To: “File Systems Developers”
>>Sent: Wednesday, July 30, 2003 14:30
>>Subject: [ntfsd] Re: FOR FAQ Re: creating system thread for create
>>
>>
>>Low on stack space?
>>
>>Jamey Kirby wrote:
>>
>>
>>
>>>Since create is always called at PASSIVE_LEVEL, why would anyone EVER
>>>need to post the request to a system thread?
>>>
>>>Jamey
>>>
>>
>>
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@nryan.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
> –
> - Nick Ryan (MVP for DDK)
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Nick Ryan (MVP for DDK)
—
You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
To unsubscribe send a blank email to xxxxx@lists.osr.com