impersonation: acrobat reader can't open documents from mirror drive mounted from under user's home directory

[bailey27]

I can't open pdfs in Adobe Acrobat Reader DC on a mirror fs if I run mirror as administrator with impersonation on and the root of the mirror fs is under my home directory (c:\Users\Bailey) or in any directory under there (e.g c:\Users\Bailey\Documents, c:\Users\Bailey\Documents\test).

If I run mirror without impersonation, either as administrator or not, I can open pdfs regardless of whether or not the root of the fs is under my home dir.

I've reproduced this problem both on my real Windows 10 64-bit system and in my Virtualbox vm.

The pdf files seem to be completely accessible and can be opened in other pdf readers (e.g. Evince).

[yin19941005]

Hi @bailey27 ,

Could you provide more information? Like dokany library version, more environment details. My use case and environment is different from you. Also, I haven't test with mirror yet but seems I am able to open the pdf file with Adobe Acrobat Reader DC (version 2018.009.20050) through a shared dokan drive (NOT mirror, but should be based on dokany-1.1.0 release).

My environment setup:

Server : Windows Storage Server 2016 version 1607 build 14393.0 (VM) Client : Windows 10 PRO version 1709 build 16299.125 (Real Machine) Using Adobe Acrobat Reader DC version 2018.009.20050

1. mount drive (start by Administrator with impersonation on) on Server and share it with SMB
2. Client connect to Server (with normal user which without admin right) and open the pdf file
3. Success open

I will try to test on mirror later on but I am quite busy recently so maybe it takes some time for me to provide the test result.

[bailey27]

I'm using Windows 10 Home 64-bit build 16299.125 and Dokany 1.1.0.

My files are all on the local c: drive.

I can reproduce the problem with Acrobat Reader only with impersonation on and only if the root of the mirror filesystem is underneath my home directory.

Did you try it with the root of the fs (the physical files) being under your home directory?

I've started debugging it using my own fs (cppcryptfs) which I've added impersonation to. The problem is reproducible with cppcryptfs under the same conditions as with mirror.

I think the reason why Acrobat Reader is throwing up the "access denied" dialog is maybe that with impersonation on and the files being under my home dir, that Acrobat is failing to open the root directory \ after succeeding to open it several times. I do not see any difference yet in the case when it fails vs. when it succeeds, other than the failed CreateFile() error = 5 for opening the directory. Even the SecurityContext->AccessState.SecurityDescriptor is null in both the successful and unsuccessful cases and all the other parameters look the same. These opens never fail with impersonation off.

[bailey27]

It looks like that if instead of using the impersonation token from DokanOpenRequestorToken() I instead get a primary logon token for myself via LongUser() and use that for impersonation, then I don't have the problem with Acrobat Reader when using impersonation and the physical files are located under C:\Users

I've verified that the impersonation functions are working with this token from LogonUser(). I did that because if the impersonation failed, then it would work anyway.

I tried using DuplicateTokenEx() to get a duplicate token from the one from DokanOpenRequestorToken() promoted to a primary token in the most deluxe fashion possible but Acrobat Reader still gets accessed denied if I impersonate using the duplicated token.

[bailey27]

If in Acrobat Reader, I got to Edit -> Preferences -> Security (enhanced) and uncheck "enable protected mode at startup", the the problem goes away.

My theory now is that Acrobat Reader is, when protected mode is enabled, using a token with permissions that don't have enough rights to do what it wants to do in the user's home directory if it thinks it is not opening a file in the the user's home directory.

[yin19941005]

Hi @bailey27 ,

Here what I got from your comment:

Summarize

All results are run mirror as administrator with impersonation on,

PDF Reader	All Directory except under C:\Users	Under C:\Users
Acrobat Reader (enable protected mode)	Pass	Failed
Acrobat Reader (disable protected mode)	Pass	Pass
Others PDF Readers (e.g. Evince)	Pass	Pass

• Using Access Token from LogonUser() (I believe you are talking about this function) to impersonate will always success

Questions :

With enable protected mode and Under C:\Users :

1. Does your account "Bailey"(Since you are testing on "c:\Users\Bailey") is an account with admin right? If yes, did you test with another account without admin right?
2. Did you tried to disable the User Account Control (UAC)(Windows enable it by default) and test the result?
3. Did you tried to run the Acrobat Reader with admin right and test the result?

Discussion

Let me talk about why I so focus on asking those stuffs with UAC and admin right first. I remember I was using dokan-0.7.4 at that time and I facing similar issue. For that issue (should with network drive option on, but not really remember the mount option setting), I was unable to save all the pdf files with Adobe Reader XI under all conditions. Finally, I come up with three solution, 1. Disable the protected mode (the sandbox), 2. Disable the Windows UAC and 3. Upgrade to Adobe Reader DC. So, in my point of view, the symptoms are quite similar and seems to be related issue.

Please read this article from Microsoft (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd835561(v=ws.10)) about User Account Control (UAC). In short, when UAC enabled, even user with admin right will just using the standard user access token without elevation. And that standard user access token should be kind of "restricted version" of the user full access token.

It seems Adobe Reader is actually requiring the "Full user access token". For user with admin rights, the token get by DokanOpenRequestorToken() should be a "restricted user token" at the first trial (just like I mentioned in #636 and failed with STATUS_PRIVILEGE_NOT_HELD). However, some how some way the call got succeed (maybe Adobe Reader didn't set the flag correctly, dokan bug, etc.), which should be failed and try to elevate, and finally failed with access denied when it requires the right. And I guess, the LogonUser() will return the "full user access token" since you are able to provide the user password (something like that). So the token returned by LogonUser() is able to run correctly.

[bailey27]

Yes, your table is correct.

That is the LoginUser() function I am talking about, and when impersonating with that token, it always succeeds.

Acrobat Reader DC is using a restricted token when it fails. I put in a test IsTokenRestricted() and a debug print.

These places where it fails all succeed when the physical files are located not in C:\Users, and the token being passed through dokany is still restricted in those calls.

However, the token being returned by DokanOpenRequestorToken() is not always a restricted one on every call.

Yes, the "Bailey" user is in the administrators group.

I tried it with UAC disabled, and the problem is still there.

If I run Acrobat Reader DC as administrator, fails as well.

In order to test access as a standard user (not in administrators group), I did this.

I ran mirror as a service (using srvstart), using impersonation.

If I login as as Bailey, I have the same problem with Acrobat Reader. But I have access to the drive in general.

If I login as "joe", a standard (non-admin) user, I cannot access anything with impersonation on, as expected, because the files are under C:\Users\Bailey.

If I have the fs mounted with the physical files under c:\Users\joe, and login as joe, then I have the same problem as before (general access works, but acrobat reader does not).

[yin19941005]

Hi @bailey27 ,

Sorry for the late reply. I had confirmed I got the following test result on my environment :

My Test Result

Dokany-1.1.0.1000 release (installed with installer) Windows 10 PRO version 160 7build 14393.0 (VM) Using Adobe Acrobat Reader DC version 2015.020.20039

PDF Reader	All Directory except under C:\Users	Under C:\Users
Acrobat Reader (enable protected mode without admin right)	Pass	Failed
Acrobat Reader (disable protected mode without admin right)	Pass	Pass
Acrobat Reader (enable protected mode with admin right)	Pass	Failed
Acrobat Reader (disable protected mode with admin right)	Pass	Pass

Base on your result: I havn't test with Access Token from LogonUser(). I havn't test with UAC off. I am testing with an account with admin right. (It seems didn't related at all)

My log and disscussion

I had captured the two log from mount drive to open the .pdf by adobe reader dc

(VMBB-PC6 is my user account name and C:\Users\VMBB-PC6\Documents\NIST_The GaloisCounter Mode of Operation(GCM).pdf is the target .pdf file)

1. With impersonation on, enable protected mode without admin right, Under C:\Users (Failed Case)
2. Without impersonation off, other condition are same (Normal Case)

On the failed case log, I found

error code = 5


CreateFile status = c0000022

(STATUS_ACCESS_DENIED) occurs in total 6 times. 3 times occur with C:\Users\VMBB-PC6\Documents, 3 times occur with C:\Users\VMBB-PC6\Documents\NIST_The GaloisCounter Mode of Operation(GCM).pdf.

I checked for the corresponding normal log and found two occurs on this operation :

CreateFile : C:\Users\VMBB-PC6\Documents\
  AccountName: VMBB-PC6, DomainName: VMBB-PC15-PC
	ShareMode = 0x7
	FILE_SHARE_READ
	FILE_SHARE_WRITE
	FILE_SHARE_DELETE
	DesiredAccess = 0x100001
	FILE_READ_DATA
	SYNCHRONIZE
	FlagsAndAttributes = 0x0
	OPEN_EXISTING

in total called 4 times in normal log with all success status while the failed case log also only called 4 times in total with 2 success and 2 failed status. This seems is mean it doesn't trying to elevate when privilege is not enough.

I guess this issue is happening is because : The Adobe Reader Protection is a sand box and preventing the elevate operation in order to provide protection but at the same time the access token returned by DokanOpenRequestorToken() is not contain sufficient privilege. In my option, if we understand the difference between the access token returned by DokanOpenRequestorToken and the access token returned by LogonUser(), then we would understand why this is happening.

@bailey27 , did you got any idea on the difference between the access tokens?

[Liryna]

Hi @yin19941005 , @bailey27 ,

I revive this old conversation 😃 I try to reproduce the issue. As I understood I should mirror my user folder with a shell with admin rights: mirror.exe /r C:\Users\liryna /l m /p enable protected mode and having adobe sandbox with protected mode) If I open any pdf on M:\ it should fail ? Maybe I am doing something wrong but I cannot reproduce it 😢

[killing]

@Liryna As you asked in https://github.com/dokan-dev/dokany/issues/794 , we continue the discussion here. You may find the mirror debug log here. The pdf file was named test.pdf.

[yin19941005]

Hi @Liryna,

Yes, I think your understanding is correct and if I remember the issue correctly. Unluckily, I didn't got any screenshot at that time. As I remember, it should be a pop up error message box from Windows. Here is the logs I captured at that time:

adobeReader_imperFail_001.LOG adobeReader_imperFail_002.LOG adobeReader_normal_001.LOG

I don't have environment for testing right now. It seems me and bailey were running test on Virtualbox VM, not sure is it related or not.

[Liryna]

Hi @yin19941005 ,

Thanks for the log and information. Am using vmware for now, could not reproduce 😢 will see on virtualbox if any chance. Would be great if you could get an env back to help me reproduce it 👍

[Liryna]

OK, good news @bailey27 , @yin19941005 , @killing this is already fixed in the last release 1.2.2.2000. I succeed in reproducing the issue with 1.2.1.2000 , do the same step with 1.2.2.2000 & master branch without facing it 👍 🏆

Does anyone could try release 1.2.2.2000 or master branch snapshot to be sure ?

[killing]

Hi @Liryna

Thank you for fixing this issue! Great work! Where can I download 1.2.2.2000 for testing?

[Liryna]

@killing https://github.com/dokan-dev/dokany/releases/tag/v1.2.2.1000

It is the 1.2.2.1000 sorry

[killing]

Hi @Liryna

We've tested 1.2.2.1000 before. But it still had the issue we mentioned in https://github.com/dokan-dev/dokany/issues/794. Have you tested that?

[Liryna]

Hi @killing,

I did the test again. Installed 1.2.2.1000, used the mirror installed with. Run mirror.exe /r C:\Users /l m and mirror.exe /r C:\Users /l m /p. Both can read pdf in sandbox at the root / subfolders of the device.

Could you give me more on how to reproduce it ?

[killing]

Hi @Liryna

I tested again, with 1.2.2.1000 and the same security settings as yours in Adobe. I got a different error message from Adobe reader.

My Adobe version is 2019.010.20098.

You may find the log of mirror program here

[infeo]

I can confirm that this issue is not fixed. My system is Windows 10 Enterprise N Ver. 1809, Dokany is installed in Version 1.2.2.1000. I checked out the current master branch, compiled the mirror example and it's dependencies and started it with

.\mirror.exe /r "C:\Users\Armin Schrenk\Documents\CheckDokanVersion" /l D /c /d /s 2>&1 >"C:\Users\Armin Schrenk\Documents\logs\dokanMirror.log"

Opening D:\ in the explorer and from there opened testFile.pdf, leading to an access denied pop-up dialogue in adobe reader.

Reproducing this is really hard, seems quite random when access is denied and when not.

I can provide logs of the dokany mirror example and the adobe secure mode. I didn't find anything suspicious in the logs.

[stforek]

I can reproduce this error on Windows 10 Pro (ver 1903), Adobe Reader 2019.010.20098 and dokan 1.3.0.1000 (reproduced on mirror.exe) In AdbeReaderBroker.log I can see:

[08:30/15:38:51] Adobe Reader Protected Mode Logging Initiated 
[08:30/15:38:51] Failed to process path:C:\Users\user\Desktop\B\file.pdf error code:3
[08:30/15:38:51] NtOpenSection: STATUS_ACCESS_DENIED

Isn't this failing function https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-zwopensection in adobe reader? Maybe dokan is returning an error for this callback?

When I turn off protected mode everything works fine.

[stforek]

One more update. When I mount as a new drive it works fine (for example it works fine if pdf is served as M:\file.pdf).

[Liryna]

Hi,

That's interesting. Could you run procmon to see at whish moment the acces denied happens?

If I understand correctly, it only happen if mount by reparse point is issued?

Le lun. 2 sept. 2019 à 12:54, Przemyslaw Ciezkowski < [email protected]> a écrit :

One more update. When I mount as a new drive it works fine (for example it works fine if pdf is served as M:\file.pdf).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dokan-dev/dokany/issues/640?email_source=notifications&email_token=ABA4S67X7CAR34SGSO7FUQLQHTWHBA5CNFSM4EI7FBN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5VPMQY#issuecomment-527103555, or mute the thread https://github.com/notifications/unsubscribe-auth/ABA4S666YUHOBYY33O6OVYTQHTWHBANCNFSM4EI7FBNQ .

[stforek]

Hi. Here is procmon dump for mirror.exe /d /s /r C:\Users\p.ciezkowski\Desktop\A /l C:\Users\p.ciezkowski\Desktop\B Pdf reading fails. https://drive.google.com/file/d/18Ejj7V4gYoP5_Rimtvl3mg7PsuiPH-XV/view?usp=sharing

Here it works fine for: mirror /d /s /r C:\Users\p.ciezkowski\Desktop\A /l M: https://drive.google.com/file/d/1Y63kDbbdNvixC6k3eHhxhg59dQv2oU1y/view?usp=sharing

[deki]

Hi, I'm also affected by this issue. @Liryna was the dump from @stforek sufficient or do you need more information?

[RomanKalachik]

Hello, Judging by the logs below. Acrobat Reader detects mounted folder when the protected mode is enabled. %user%AppData\Local\Temp\AdbeReaderBroker.log

[01:19/19:53:36] requested path: ??\G:\a\re Used Report .pdf [01:19/19:53:36] actual path: \Device\Volume{d6cc17c5-1724-4085-bce7-964f1e9f5de9}\a\re Used Report .pdf [01:19/19:53:36] Invalid Object found [01:19/19:53:36] NtCreateMutant: STATUS_ACCESS_DENIED

Also, here is a link to a Acrobat Reader Protected Mode reference. https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/sandboxprotections.html

[infeo]

A short update for this issue: As described in the above linked issue of the winfsp project, Adobe Acrobar Reader tries to interpret a reparse point by itself and fails doing so. The project maintainer opened an request at Adobe, which would benefit every project provinding virtual volumes.

It can be upvoted to gather more attention, so don't hesitate: https://acrobat.uservoice.com/forums/926812-acrobat-reader-for-windows-and-mac/suggestions/39652114-acrobat-reader-unable-to-access-files-via-junction#comments

[Liryna]

@infeo Thanks ! good to know we are far from being alone on this

[infeo]

There are user reports of applications using Dokany that indicate this might be fixed in Adobe Acrobat Reader DC version 2021.001.20138.

~~Can this be verified?~~

It is partially fixed. If the virtual filesystem is mounted as a volume, it works now without an error. If the mount point is directory/ reparse point, it still fails intermittently. This behaviour is the same described in the linked winfsp issue, so there still needs to be some work done by Adobe.