EldoS | Feel safer!

Software components for data protection, secure storage and transfer

OnSetFileAttributes missing FILE_WRITE_ATTRIBUTES

Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.
Posted: 07/04/2016 05:15:49
by Glen Keech (Premium support level)
Joined: 06/20/2016
Posts: 4


When opening the file properties dialog in explorer in windows 10, my .NET callback FS receives an OnSetFileAttributes callback, however the access mask in the preceding OnOpenFile callback does not include FILE_WRITE_ATTRIBUTES.

  DesiredAccess=0x00120089 (FILE_GENERIC_READ)

  Path=\New Text Document.txt,
  Creation=01/01/0001 00:00:00,
  LastAccess=04/07/2016 09:47:52,
  LastWrite=01/01/0001 00:00:00,
  Changed=01/01/0001 00:00:00,

When actually setting a file property in the properties dialog, such as the archive bit, this does result in an OnOpenFile callback with the appropriate access mask bit set (0x100).

I wanted to check if this is a CBFS issue or normal windows behaviour.

Posted: 07/04/2016 10:13:18
by Glen Keech (Premium support level)
Joined: 06/20/2016
Posts: 4

I'm seeing a similar issue where I receive the following sequence of callbacks:

OnCreateFile, Access Mask: 0x001001a3

The access mask passed in OnCreateFile does not include the DELETE bit (0x00010000), so my callback wants to return access denied from the OnCanFileBeDeleted callback.

However when I look in process monitor, I see 3 discrete CreateFile operations, and the 3rd one which calls SetDispositionInformationFile does actually specify delete rights.

CreateFile                    N:\...67f5.rgt   NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
CreateFile                    N:\...67f5.rgt   SUCCESS        Desired Access: Read Data/List Directory, Write Data/Add File, Execute/Traverse, Read Attributes, Write Attributes, Synchronize, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: HN, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created
WriteFile                     N:\...67f5.rgt   SUCCESS        Offset: 0, Length: 36, Priority: Normal
CloseFile                     N:\...67f5.rgt   SUCCESS   

CreateFile                    N:\...67f5.rgt   SUCCESS        Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
QueryBasicInformationFile     N:\...67f5.rgt   SUCCESS        CreationTime: 04/07/2016 14:18:28, LastAccessTime: 04/07/2016 14:18:28, LastWriteTime: 04/07/2016 14:18:28, ChangeTime: 01/01/1601 01:00:00, FileAttributes: A
CloseFile                     N:\...67f5.rgt   SUCCESS   

CreateFile                    N:\...67f5.rgt   SUCCESS        Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
QueryAttributeTagFile         N:\...67f5.rgt   SUCCESS        Attributes: A, ReparseTag: 0x0
SetDispositionInformationFile N:\...67f5.rgt   ACCESS DENIED  Delete: True
CloseFile                     N:\...67f5.rgt   SUCCESS   

So far I've been working under the assumption that there will be a 1:1 mapping between win32 CreateFile and OnCreateFile/OnOpenFile callbacks, that my callback filesystem should track these handles and access masks and enforce the access and sharing mode logic whenever a callback is invoked.

Is CBFS enforcing the handle access mode / sharing mode logic at the kernel level, such that if a callback is made then the file handle is assumed to have appropriate rights to invoke that operation?

E.g. if OnSetEndOfFile is called, has CBFS already checked for FILE_WRITE_DATA / FILE_APPEND_DATA at the kernel level?

If the user mode callback FS is responsible for enforcing handle access rights, then it seems the driver needs to expose all of the CreateFile / CloseFile operations to the callback FS so it can have a full view of the file handles.

Edit: Just found 'CallAllOpenCloseCallbacks'; I see what's going on now from the documentation.

Posted: 07/05/2016 03:43:56
by Volodymyr Zinin (EldoS Corp.)

Hi Glen,

Perhaps the problem is because the CallbackFileSystem property CallAllOpenCloseCallbacks is set to FALSE. Please check it first.

Also there can be a situation when "write", "delete" or "set file attributes" occurs after file opening without required access rights. It can be done by kernel mode components (usually file system filter drivers like antiviruses). Such components can open a file with zero rights, then compose a write or delete request and send it to the file system driver. In such case the access rights are not checked and NTFS, FATFS process such request correctly. In the case of CBFS it is up to you to allow or prohibit such operations.
Posted: 07/05/2016 04:49:32
by Glen Keech (Premium support level)
Joined: 06/20/2016
Posts: 4

Hi Volodymyr,

Thanks, CallAllOpenCloseCallbacks does indeed resolve the problem.

Can you please confirm whether the CBFS driver enforces applicable windows access mask and sharing mode logic on the handle before making any callbacks, both when CallAllOpenCloseCallbacks is enabled and disabled?

I.e will the driver return ERROR_ACCESS_DENIED and ERROR_SHARING_VIOLATION on win32 API calls, without invoking the user mode filesystem callbacks, if:
a. Handles do not have rights for the given operation (e.g. attempt to write/extend/truncate file without write/append access on the handle)
b. Handles to the same file are open with sharing modes incompatible with subsequent calls to CreateFile for the same handle.

If the driver is enforcing all of this then it would be preferable for us to set CallAllOpenCloseCallbacks false and remove the access and sharing mode checks from our user mode filesystem callbacks. The goal is to promote expected behaviour of win32 API calls, so to improve application compatibility with our filesystem. Whether this is done in the kernel or in user mode doesn't matter.

Posted: 07/05/2016 06:58:00
by Volodymyr Zinin (EldoS Corp.)

Yes, the CBFS driver checks and handles access rights and share access and returns the "access denied" error when it's necessary without calling the OnOpen callback. So it isn't necessary to do the same in your callback. But the additional check of access rights can be required if the "backend" files, you are using in your callbacks, can be opened outside CBFS callbacks too. For example there are several CBFS instances on different machines which all use in parallel the same backend storage.
Posted: 07/20/2016 11:54:08
by Glen Keech (Premium support level)
Joined: 06/20/2016
Posts: 4

Hi Volodymyr,

Thanks for confirming, CBFS has been performing well with CallAllOpenCloseCallbacks disabled.

The shared back end storage case is of interest. In this scenario multiple CBFS based clients might access a central server. The central server might issue virtual file handles to the clients to regulate shared access. In this case CallAllOpenCloseCallbacks would come into play.

How does CBFS express LockFile(Ex) in terms of callbacks, for purposes of the user mode file system delegating the tracking of such access to the central server in this scenario?

Posted: 07/21/2016 03:04:53
by Volodymyr Zinin (EldoS Corp.)

CBFS processes LockFile requests internally. I.e. it works for CBFS virtual disks but there are no corresponding callbacks. We have plans to make such callbacks in future versions. But now, in the case of the shared back end storage, the only way is to lock a back end file at whole if it is opened for write access.
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.



Topic viewed 1706 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!