filesystem watcher and more

[hugomind]

Hi,

I need to catch the domainname/username as additional information when
the Filesystemwatcher throws en event ?
If someone is creating, deleting or changing perms of a file I would
need to know who it was.

Could some give me a hint how to accomplish this ?

thnx,
Hugo

 

[Peter Bromberg [C# MVP]]

I cannot think of any way this could be reliably done. FileSystemWatcher
events expose the file or foldername and what kind of action and that's it.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com

 

[Ignacio Machin \( .NET/ C# MVP \)]

H,

I do not thing this can be done.
You could do it locally, but not on a network environment

 

[Carl Daniel [VC++ MVP]]

Hi,

I need to catch the domainname/username as additional information when
the Filesystemwatcher throws en event ?
If someone is creating, deleting or changing perms of a file I would
need to know who it was.

Could some give me a hint how to accomplish this ?

The only way this could be done (I think) is using a file system filter
driver. Please don't attempt it unless you've got several years experience
writing kernel device drivers. Even a filter driver won't help for remote
(network share) files - only local files.

-cd

 

[hugomind]

I cannot think of any way this could be reliably done. FileSystemWatcher
events expose the file or foldername and what kind of action and that's it.
-- Peter
Site:http://www.eggheadcafe.com
UnBlog:http://petesbloggerama.blogspot.com
MetaFinder:http://www.blogmetafinder.com

Locally is fine, I would use a client on the local maschines, how
would you do it ?

Thnx
Serge

 

[hugomind]

Locally is fine, I would use a client on the local maschines, how
would you do it ?

Thnx
Serge

Oh a filter driver, well, hmm is not easy for me... does someone know
some good resources, groups, books so that I can start with this.
If it's the only way then I need to start with it...

Examples would be great.

Thanks Hugo

 

[christery]

start looking at secedit if in m$,
*nix I dont know(but there will be somone who knows *nix somewhere),
set audit in vms...
the normal os has (sometimes) it built in...not DOS though, nor OS/2
as far as I know.

dont start writing near kernel code if u dont have to. but if u do,
please report...
//CY

 

[Willy Denoyette [MVP]]

Hi,

I need to catch the domainname/username as additional information when
the Filesystemwatcher throws en event ?
If someone is creating, deleting or changing perms of a file I would
need to know who it was.

Could some give me a hint how to accomplish this ?

thnx,
Hugo

Turn on file auditing (Access - Successful ) for the "Authenticated Users"
on the File and/or Directories you care about, an event will be written to
the security log provided you did enable "Object Access" Auditing in the
Local Policies.
The security log entry will tell you who's did what on the FS object.
Even with a FS filter driver it's not possible to get at this info, you are
to low in the IO stack to get at this info, which is only accessible by the
security subsystem system in the kernel.

Willy.

 

[hugomind]

Turn on file auditing (Access - Successful ) for the "Authenticated Users"
on the File and/or Directories you care about, an event will be written to
the security log provided you did enable "Object Access" Auditing in the
Local Policies.

The security log entry will tell you who's did what on the FS object.
Even with a FS filter driver it's not possible to get at this info, you are
to low in the IO stack to get at this info, which is only accessible by the
security subsystem system in the kernel.

The Eventlog is not an option in this case, any sysadmin could disable
it, but why does an fs filter driver not work ? How does filemon from
sysinternals solve this problem ?

thnx,
Hugo

 

[Willy Denoyette [MVP]]

The Eventlog is not an option in this case, any sysadmin could disable
it, but why does an fs filter driver not work ? How does filemon from
sysinternals solve this problem ?

thnx,
Hugo

Oh I see, you don't trust your Admins, installing a FS Filter driver won't
help you because Admins can uninstall them easily, or they can run as
(command "runas") some other user and do whatever they like on their behalf.
That said, Filemon (a tool now replaced by Process Monitor) is a complex
diagnostics tool (something you should not write using managed code) that
uses a FS Filter driver (something you can't write using managed code) to
capture IRP and FASTIO requests and pass the parsed contents back to a user
portion of the program that keeps track of the running processes and their
corresponding file handles. The file info is obtained by peeking in the
running processes handle table in order to find the file object
corresponding to the file handle. Here you have your first issue, where to
find the handle table in a running process? there are no documented API's
for this, the author of the tool knows the internal API's and how to use
them and when. The second issue is related to impersonation, the tool can
only catch the UserId of the process issuing the IO request, not the ID of
the thread in case of an impersonated thread. So in case of an impersonated
client, you are getting the process UserId, not the ID of the issuing
client.
And a third issue is that you'll need to process *sequences* of IRP's in
order to know exactly what's happening to a File. For instance when deleting
a File, an IRP_MJ_SETINFORMATION is sent down the IO stack followed by an
IRP_MJ_CLEANUP and an IRP_MJ_CLOSE, these events do not necessarily follow
each other directly, the sequence can get intermixed by other events AND you
need to keep track of the return status of each event in the sequence. This
means processing overhead, especially on a busy system.
Supposing you can solve all above issues, you still need to trust your
Admins not to kill this process, so why not simply trust them and use the
File Systems auditing facility which was specially made for such task?

Willy.