Allowing only file attribute updates

NTFSD
1

In my filter driver, I want to allow applications to update some file
attribute bits (such as the Archive bit), but don’t want to allow any data
or ACL modification.

I know I can return ACCESS_DENIED on Create if the Create IRP requests
anything more than FILE_WRITE_ATTRIBUTES access. But what happens if I
allow the Create, then want to allow modification of only CERTAIN attributes
while denying others? I seem to recall that returning ACCESS_DENIED in
response to SetInformationFile IRPs might confuse some applications. Does
anyone have opinions or suggestions?

Thanks,
Carl

2

I think that, if done correctly, this won’t confuse any application. If it
uses SetFileAttributes API, the API will handle the error code and return it to
the application. If it uses some more direct, it is smart enough to handle it.

Regards, Dejan.

Carl Appellof wrote:

In my filter driver, I want to allow applications to update some file
attribute bits (such as the Archive bit), but don’t want to allow any data
or ACL modification.

I know I can return ACCESS_DENIED on Create if the Create IRP requests
anything more than FILE_WRITE_ATTRIBUTES access. But what happens if I
allow the Create, then want to allow modification of only CERTAIN attributes
while denying others? I seem to recall that returning ACCESS_DENIED in
response to SetInformationFile IRPs might confuse some applications. Does
anyone have opinions or suggestions?

Thanks,
Carl

You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to %%email.unsub%%

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com ICQ#: 56570367
Alfa File Monitor - File monitoring library for Win32 developers.
Alfa File Protector - File protection and hiding library for Win32 developers.

3

FILE_WRITE_ATTRIBUTES does not include the right to modify any security
information associated with the file. For this, the requestor needs to
ask for WRITE_DAC (for modifying the DACL), WRITE_OWNER (for setting the
owner), ACCESS_SYSTEM_SECURITY (for modifying the SACL), or READ_CONTROL
(for READING any security information except for the SACL). This is as
fine-grained as it gets, however.

If you want anything more and you’ll need to allow the create and either
deny or ‘neuter’ any subsequent calls to alter the attributes.
‘Neutering’ (returning STATUS_SUCCESS but doing nothing) may be a better
choice than simply returning STATUS_ACCESS_DENIED. Some functionality,
such as Offline Files, will not work if it receives a failure return
code trying to do something like set the compression flag, but will work
if it receives a success return code, regardless of whether the
operation was actually performed or not.

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Carl Appellof
Sent: Friday, September 27, 2002 5:36 PM
To: File Systems Developers
Subject: [ntfsd] Allowing only file attribute updates

In my filter driver, I want to allow applications to update
some file attribute bits (such as the Archive bit), but don’t
want to allow any data or ACL modification.

I know I can return ACCESS_DENIED on Create if the Create IRP
requests anything more than FILE_WRITE_ATTRIBUTES access.
But what happens if I allow the Create, then want to allow
modification of only CERTAIN attributes while denying others?
I seem to recall that returning ACCESS_DENIED in response to
SetInformationFile IRPs might confuse some applications.
Does anyone have opinions or suggestions?

Thanks,
Carl

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to %%email.unsub%%

4

Hi!
Denying the CREATE really could break something. On the create it might be
possible to change the DesiredAccess to only being one of 0x180 (I think
this was READ/WRITE_ATTRIBUTES) or being WRITE_ATTRIBUTES|GENERIC_READ(or
similar). This will cause the FS to deny all operation beyond
setting/reading attributes or reading data, so you don’t have to care about
this. In MJ_SET_INFORMATION you then later should receive a
FILE_ATTRIBUTE_TAG_INFORMATION structure, in which you can set the
attributes. Anyway, some applications could have problems with it, because
they do not get informed of the attributes manipulation you do to their
requests. Also they might terminate if sudden access is forbidden by the FS.
So here you possibly should substitute a SUCCESS in the WRITE-callbacks. And
also this could lead to trouble, when an application thinks a sudden access
succeeded, but the data returned in a subsequent call is a zero-buffer or
something.

I think you’ll have to try out which combination of options for this
approach works in your situation.

Tobias

----- Original Message -----
From: “Carl Appellof”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Saturday, September 28, 2002 2:36 AM
Subject: [ntfsd] Allowing only file attribute updates

> In my filter driver, I want to allow applications to update some file
> attribute bits (such as the Archive bit), but don’t want to allow any data
> or ACL modification.
>
> I know I can return ACCESS_DENIED on Create if the Create IRP requests
> anything more than FILE_WRITE_ATTRIBUTES access. But what happens if I
> allow the Create, then want to allow modification of only CERTAIN
attributes
> while denying others? I seem to recall that returning ACCESS_DENIED in
> response to SetInformationFile IRPs might confuse some applications. Does
> anyone have opinions or suggestions?
>
> Thanks,
> Carl
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@linkwave.org
> To unsubscribe send a blank email to %%email.unsub%%