Multi-user session issues

[LTRData]

When multiple users are logged on simultaneously such as at remote desktop servers, UNC names from their different user sessions are not kept isolated by dokannp2.dll. For example, if user1 logs on and mounts drive D: with UNC name \Name\user1\files and user2 logs on and mounts their D: with UNC name \Name\user2\files, then NPGetConnection returns one of these UNC paths when querying D: in both sessions. For example, it could return \Name\user1\files for both users.

This is not an issue when enumerating network connections such as net use command, since NPOpenEnum takes session ids into account during the enumeration. But it is an issue with NPGetConnection and therefore also other APIs that depend on it, such as NPGetUniversalName. This means that Explorer windows display wrong connection path under the icon for all users except one of them.

I am about to make a PR that fixes this.

There is also an issue when two users use the exact same UNC path, such as user1 mounting D: with UNC path \Name\files and user2 mounting their D: with UNC path \Name\files. When using that UNC path, it will end up on either user's mounted drive. This is only an issue when the UNC path is used instead of drive letter. It is much more difficult to find out what could be done about this. Anyone have any ideas about that?

[LTRData]

My idea is this. We change DokanGetMountPointList in kernel mode so that for non-admins, it skips drives from other sessions than requestor's session. Admins still get all information so that there is a way to enumerate and dismount everything mounted. This ensures that kernel driver never leaks information about other users' mounted drives to non-privileged users while admins still can do dokanctl /l to see everything mounted.

Then, in user mode NPGetConnection we change so that it also filters on session number so that applications using network redirector API only get information about user's own mounted drives, so that Explorer windows show correct information both for admins and non-admins.

[Liryna]

Yeah that seems the right way to do!

Additionally (and maybe not related) we could try to see if FsRtlRegisterUncProvider (same for FsRtlDeregisterUncProvider) really needs to be run in a system thread which I believe is not the case.

dokany/sys/fscontrol.c

Line 955 in 6a412d7

RunAsSystem(DokanRegisterUncProvider, dcb);

dokany/sys/init.c

Line 767 in 6a412d7

FsRtlRegisterUncProvider(&(Dcb->MupHandle), Dcb->DiskDeviceName, FALSE);

[LTRData]

Good idea. I can do some experiments with that too and see if the behaviour changes somewhere if they are called from other context than a system thread.