Access Token in DeleteFile callback

[Akash Jain]

Hi

I am using the Dokany as SMB share with Network Share created on a local mount point. 

I was working on handling DeleteFile Dokan Callback and I wanted to explicitly perform the access check to see if the logged on user over SMB share has required permissions on the file. I am seeing 2 issues here:

1. There is no access token passed to use it directly for access check. 

2. We could have stored the access token inside opaque context in the File Handle when we got createFile callback. But there is no handle passed to deleteFile. 

Any ideas how we can perform access check in callbacks like deleteFile, deleteDirectoy, moveFile etc?

Thanks

Akash

[Adrien JUND]

Hi Akash,

During the CreateFile event, you can set a Context in the DokanFileInfo that can be whatever you want.
Then during the DeleteFile event you can get back this Context from the DokanFileInfo provided.
With it you will be able to check your permission https://github.com/dokan-dev/dokany/blob/master/samples/dokan_mirror/mirror.c#L874

Best regards,
Liryna

--
You received this message because you are subscribed to the Google Groups "Dokan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dokan+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dokan/15a7c263-1bbd-45fb-9887-afc1cf022419n%40googlegroups.com.

[Akash Jain]

Hi

Thanks for the response. Let me clarify it more:

1. I checked the DokanFileInfo->Context and it is not a valid handle to use. That's what I meant when I said " But there is no handle passed to deleteFile."

2. I have AccessCheck in the createFile and it fails so I am returning ERROR_ACCESS_DENIED so the handle is not valid anymore. I get the DeleteFile callback after the failed createFile callback.

Thanks

Akash 

You received this message because you are subscribed to a topic in the Google Groups "Dokan" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dokan/xl-wyvkHExo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dokan+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dokan/b6e87385-8579-9865-8bd4-c47f1b8619b2%40gmail.com.

[Akash Jain]

Another data point I forgot to add is:

1. I am testing the Deny Delete permission case. So I am expecting the DeleteFile callback to fail with AccessCheck() returning error. 

2. This happens typically with Linux SMB client. It directly calls DeleteFile callback. 

3. With Windows SMB client, the observed behavior is different. We do not see DeleteFile callback but it only tries with Delete On Close I believe. Even after we return error from createFile on the file, it checks on access permissions on parent folder and if there is no error, it thinks that file is deleted but actually it is not. So it reappears in explorer. 

Any help is appreciated. 

Thanks

Akash

[Adrien JUND]

I am not sure it is possible to get a DeleteFile without having a previous CreateFile succeeding. Could you share a procmon log where this happens ?

To view this discussion on the web visit https://groups.google.com/d/msgid/dokan/CAK7vXC5xxc-C%2BvYg2auXwEhMKEbLV9-YUz-uJEBXbrgSazcTqA%40mail.gmail.com.

[Akash Jain]

Hi Adrien

I could not get the procmon log over SMB share. But I can confirm this is happening only with Linux SMB clients. I currently fixed it with handling NULL handle in DeleteFile callback (and few other) to avoid the invalid operation to continue when it's not allowed. 

Thanks

Akash

To view this discussion on the web visit https://groups.google.com/d/msgid/dokan/CABr8oZDAdqD%2BGgR1N1_GanDDReHXu-uv5M1fdtKgGVB0qjEqVQ%40mail.gmail.com.