Re[4]: Get the name of the user writing to a file

NTFSD
1

If you monitor and try to deny Paging I/O writes, which happen in the case of memory

mapped /cached files, the > originator will always be SYSTEM.

And then? You let it pass?

Anyway if you don’t let it pass, you will get that dreaded

“Delayed write failed” information message in Windows shell

and the file will be corrupt.

So denying paging writes is a very bad idea.

L.

2

sir,
I am working on PCI Windows Driver programming using vc++. How to write windows driver code for read and write functions to access BAR registers and how to detect PCI device from driver code.

----- Original Message ----
From: Mark Roddy
To: Windows File Systems Devs Interest List
Sent: Friday, 23 November, 2007 8:39:31 PM
Subject: Re: [ntfsd] Get the name of the user writing to a file

Generally you want to do this sort of thing in the create path, and not try to acquire the information in the write path.

On Nov 23, 2007 6:28 AM, wrote:

Is it possible to get the SID when catching the Write IRP?

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:

http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@hollistech.com

To unsubscribe send a blank email to
xxxxx@lists.osr.com

–
Mark Roddy

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com

Did you know? You can CHAT without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php/

3

>Anyway if you don’t let it pass, you will get that dreaded

“Delayed write failed” information message in Windows shell

and the file will be corrupt.

So denying paging writes is a very bad idea.

True indeed. J

However, I have a question.

Suppose a filter gets and saves the User SID in IRP_MJ_CREATE and uses that to identify the user in the further IRPs that it receives .

Let’s assume for time being that calls are NONCACHED. Basically, the file is opened with FILE_NO_INTERMEDIATE_BUFFERING flag.

Let’s say a process P1 (User: U1) opens a file. A FILE_OBJECT is created. The filter associates the User SID with this FILE_OBJECT.

What if the process (P1) calls DuplicateHandle to create a handle and give it to some other process , P2(User:U2).

Now we have two handles referring to the same FILE_OBJECT.

Now, if P2 issues a Write call, the Write IRP will come in context of User U2. However, the filter will report it as U1.

What should be done in this case?

Regards,

Ayush Gupta.