The nfs server of W2K12 (±R2) uses now MAXIMUM_ALLOWED for all opens (files or folders) - compared to earlier versions.
The msdn spec, google etc. do not tell much about this.
Some questions:
a) Is there a way to query what rights are granted with the open using this DessiredAccess value?
c) I also saw that using this right via CreateFile will be translated in a combination of this right and other rights. Is my assumption correct, that this means the other rights have to match and the rest is based on MAXIMUM_ALLOWED?
b) What is the purpose of this flag or vice versa, why should a developer consider the single desired access rights instead of always using MAXIMUM_ALLOWED? This would be much easier.
Thx
Norbert
The granted access is returned in the GrantedAccess field, but this doesn’t seem to be visible via the API call ({Zw,Nt}CreateFile). It’s easily seen in a mini-filter.
The idea with MAXIMUM_ALLOWED is that the rights requested will be trimmed down to what you can get. If you can’t have *any* access to the object, the create fails (access denied).
It’s really pretty unusual to see it in the XxCreateFile functions. But other functions (ZwOpenProcess for example) do use it in fairly obvious ways.
NTFS will attempt to strip out access that you can’t be given. So if you request FILE_WRITE_DATA access on a read-only file, it strips out FILE_WRITE_DATA (for example). In the end, you have a handle that permits you to do as much as security allows.
I agree it’s not especially well documented.
Tony
OSR
The granted access is returned in the GrantedAccess field, but this doesn’t seem to be visible via the API call ({Zw,Nt}CreateFile). It’s easily seen in a mini-filter.
[/quote]
As I recall, {Zw,Nt}QueryInformationFile w/FileAccessInformation should do the trick.
What is the purpose of this flag or vice versa, why should a developer consider the single desired access rights instead of always using MAXIMUM_ALLOWED? This would be much easier.
[/quote]
I don’t know how MAXIMUM_ALLOWED is supposed to interact with other handles’ ShareAccess. For example, what happens if you open with MAXIMUM_ALLOWED and you have FILE_WRITE_DATA access to the file but another handle does not have FILE_SHARE_WRITE? Does it succeed without giving you FILE_WRITE_DATA, or do you get a STATUS_SHARING_VIOLATION? I have not tried this to check. The documentation I have seen does not make that clear.
- Danilo
Added MAXIMUM_ALLOWED to FileTest.
@Ladislav: I had in mind to ask you for adding this flag to your FileTest. 
@Toni: I added the Iopb->Parameters.Create.SecurityContext->AccessState->PreviouslyGrantedAccess
and it shows me what I asked for - Thx.
I read some threads here about modifying the DesiredAccess but didn’t found a answer about this (W2K12 R2 and MS nfs server connected from ubuntu):
I striped down my file system filter driver to change the DesiredAccess in the PreCreate (when MAXIMUM_ALLOWED flag is set) of a file:
a_data_p->Iopb->Parameters.Create.SecurityContext->DesiredAccess = FILE_READ_DATA;
a_data_p->Iopb->Parameters.Create.SecurityContext->AccessState->OriginalDesiredAccess = FILE_READ_DATA;
a_data_p->Iopb->Parameters.Create.SecurityContext->AccessState->RemainingDesiredAccess = 0;
FltSetCallbackDataDirty( a_data_p );
And printed out also the AcessState values in the PostCreate.
The PostCreate showed always FILE_READ_DATA for DesiredAcess - as expected.
The szenario I found is, that my user app (same with FileTest from Ladislav) opens the file with MAXIMUM_ALLOWED and gets AccessDenied when it tries to delete the file (via SetDispostionInformationFile). More precisely, the IRP is not shown in ProcessMonitor. So I assume the IO-Manager checks the rights and does not forward the API call.
But I’m able to delete the file via nfs. In this case, the system process opens the file also with MAXIMUM_ALLOWED and the SetDispostionInformationFile is not denied and successful completed by ntfs. The file is deleted.
Although my filter changes the DesiredAcess in both cases to FILE_READ_DATA.
What did I miss?