For opening an existing file case (not create), I am retrieving Desired Access from irp and removing write related bits from the desired access of the irp. It appears to be working. I wanted to make sure
(1) This is really a proper way to remove additional access rights of the Open related IRP arriving from the user space.
(2) Removal of the bits indeed really works with no issues later (of course f the app attempts to write, I expect the write to fail NOT BSD)
Thx
It is unclear (at least to me) what you are trying to achieve here.
Is it your intention to remove the write related bits from the DesiredAccess field in order to create a read-only behaviour?
Best regards,
Razvan
Sorry,
“Is it your intention to remove the write related bits from the DesiredAccess
field in order to create a read-only behaviour?” Yes that is exactly what I would like to do without causing any OS specific issues.
Thx
> For opening an existing file case (not create), I am retrieving Desired Access from irp and removing
write related bits from the desired access of the irp. It appears to be working.
Strange. At least for some write paths, the only check in the kernel is the Ob’s granted access bits accompanying the handle, and nothing else, the FSD does not know in some cases that the file is read-only.
The very idea looks amazingly bad. The proper way to disallow writing is just to fail MJ_CREATE with access denied if you dislike the desired access.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
As usual, Maxim is right.
This means that although the OP removes those bits from DesiredAccess, the open handle would still have the requested write access, because the checks are made on the bits of the handle, which will contain all the requested bits in case the create succeeded.
There is a common misconception in the file system being the authority when thinking about the allowed operations on a file, but the truth is that most the security checks are made only at IRP_MJ_CREATE time. Once the open succeeded there will be no more checks (except byte range locks) to decide whether a write is allowed or not when an IRP_MJ_WRITE hits the file system.
I’ve written more about this here: http://tinyurl.com/ab8hrb
Best regards,
Razvan
This desiredAccess feature is processed in io manager as opposed to file
system?
wrote in message news:xxxxx@ntfsd…
> For opening an existing file case (not create), I am retrieving Desired
> Access from irp and removing write related bits from the desired access of
> the irp. It appears to be working. I wanted to make sure
> (1) This is really a proper way to remove additional access rights of the
> Open related IRP arriving from the user space.
> (2) Removal of the bits indeed really works with no issues later (of
> course f the app attempts to write, I expect the write to fail NOT BSD)
>
> Thx
>
>
… chuckle … looks like I’m alseep at the wheel tonight 
wrote in message news:xxxxx@ntfsd…
> For opening an existing file case (not create), I am retrieving Desired
> Access from irp and removing write related bits from the desired access of
> the irp. It appears to be working. I wanted to make sure
> (1) This is really a proper way to remove additional access rights of the
> Open related IRP arriving from the user space.
> (2) Removal of the bits indeed really works with no issues later (of
> course f the app attempts to write, I expect the write to fail NOT BSD)
>
> Thx
>
>
Thx for replies. In my MiniFilter driver, I am simply following:
http://msdn.microsoft.com/en-us/library/ms792918.aspx
The example assigns NewAccess (DELETE or FILE_WRITE_DATA) to desired access. In my case, I am removing selected bits before IRP_MJ_CREATE returns. By doing that app layer will have the (I am assuming, like the example) will have the desired access set in the IRP_MJ_CREATE
Thx
The example you mentioned relates to processing done inside a file system driver, not in a file system filter.
The file system augments the DesiredAccess value to be checked against the ACLs in the security descriptor in order to decide whether the create will succeed or not. The comment says:
//
// If the caller does not have restore privilege, they must have write
// access to the EA and attributes for overwrite or supersede.
//
That means the caller not having restore privilege implies that the caller should have asked for “write access to the EA and attributes for overwrite or supersede”, so the file system augments the DesiredAccess value in order to reflect that implication.
This doesn’t mean the caller will get bonus access besides what he asked. Changing the DesiredAccess value in the filters/FS driver stack does not result in the changes being propagated to the access bits of the handle.
Razvan Hobeanu wrote:
…
There is a common misconception in the file system being the authority when thinking about the allowed operations on a file, but the truth is that most the security checks are made only at IRP_MJ_CREATE time. Once the open succeeded there will be no more checks (except byte range locks) to decide whether a write is allowed or not when an IRP_MJ_WRITE hits the file system.
True as far as it goes.
But, the filesystem performs access checks at its layer and saves those
off for future reference. There are operations where those are checked
again - at the filesystem layer - so succeeding a writer handle by
re-sending the request with DesiredAccess==0 may or may not allow the
caller to perform their intended action. This is particularly true with
FSCTLs, where the access checks performed by Iomgr are essentially
inadequate due to coarseness (one bit for read, one for write…sheesh.)
Of course, since the document required a kernel driver, there would be
nothing preventing it from mucking with the filesystem’s access bits to
override this behavior. We still have hacks in the system to enable
filters to set the “WriteAccess” flag in the FileObject explicitly to
enable certain behaviors on read only handles.
In addition, it is not strictly true that writes can occur on reader
handles without consequence. This has been true traditionally on NTFS
with simple files, and many people have taken dependencies on it, but it
is not required behavior. Note that, for example, a transactional
reader handle has very different meaning to a transacted writer -
letting an app write to a transacted reader handle will not be handled well.
–
This posting is provided “AS IS” with no warranties, and confers no rights