Author: schinagl
Subject: Help on Symbolic Link Driver for WindowsXP
Posted: 03 May 2014 at 7:20pm
Hi
I have a weird question to you driver experts:
I have the freely(see later) available source for a filterdriver for symbolic links under WindowsXP, and the guy who wrote it does not
maintain it anymore. This driver works pretty well, except when it comes to resolve symlinks on mapped network drives. Then it
returns an error code.
Why do I care? Well I develop a free tool which is a 'NTFS swiss army knife', when it comes to copy hardlink structures, junctions,
symbolic links, and so on: http://schinagl.priv.at/nt/ln/ln.html. And my tools supports also WindowsXP. With the help of the symbolic link
driver. It is not the core functionality, but nice to have.... because we can ;-)
So far so good.
I am searching for an expert to help on how to fix this problem of the driver. If you are interested read on, else ....;-)
The problem with resolving symbolic links starts in the method SymlinkResolveLink() in line 1886:
lpToken = PsReferenceImpersonationToken(Irp->Tail.Overlay.Thread,
&CopyOnOpen, &EffectiveOnly, &ImpersonationLevel);
if (lpToken) {
KdPrint(("Maybe request from SRV. status=%08x path=%S\n", Irp->IoStatus.Status, fullPathName));
PsDereferenceImpersonationToken(lpToken);
Irp->IoStatus.Status = STATUS_STOPPED_ON_SYMLINK;
Irp->IoStatus.Information = 0;
return;
}
It very much looks like, that when you resolve symbolic links on local filesystems, there is no need to get an access token from
PsReferenceImpersonationToken(), and the code goes on and succeeds.
But when you are on a mapped network drive, PsReferenceImpersonationToken() will return a token, and from browsing the code I
strongly believe, that the author didn't want to bother with the returned token and always returns STATUS_STOPPED_ON_SYMLINK.
So an intentional stopper on mapped network drives.
But to tackle with access token is I guess standard coding for a experienced driver developer:
Check if we get an access token, and if yes then continue, and if no then return STATUS_STOPPED_ON_SYMLINK.
So in other words: Do not give up immediatley, but at least try to resolve the token, because it might be easy. Am I right?
What do I need: Help. I guess I can manage to compile the driver, but I do not have the experience to find the right lines of
code for this token access check.
The driver was written by Masatoshi Kimura, is freeware, and can be downloaded from http://homepage1.nifty.com/emk/symlink-1.06-src.zip
My tools are also freeware and are available under http://schinagl.priv.at/nt/ln/ln.html and use the driver.
Anyone willing out there to help two freeware projects?
Ciao and thanks
Hermann
Subject: Help on Symbolic Link Driver for WindowsXP
Posted: 03 May 2014 at 7:20pm
Hi
I have a weird question to you driver experts:
I have the freely(see later) available source for a filterdriver for symbolic links under WindowsXP, and the guy who wrote it does not
maintain it anymore. This driver works pretty well, except when it comes to resolve symlinks on mapped network drives. Then it
returns an error code.
Why do I care? Well I develop a free tool which is a 'NTFS swiss army knife', when it comes to copy hardlink structures, junctions,
symbolic links, and so on: http://schinagl.priv.at/nt/ln/ln.html. And my tools supports also WindowsXP. With the help of the symbolic link
driver. It is not the core functionality, but nice to have.... because we can ;-)
So far so good.
I am searching for an expert to help on how to fix this problem of the driver. If you are interested read on, else ....;-)
The problem with resolving symbolic links starts in the method SymlinkResolveLink() in line 1886:
lpToken = PsReferenceImpersonationToken(Irp->Tail.Overlay.Thread,
&CopyOnOpen, &EffectiveOnly, &ImpersonationLevel);
if (lpToken) {
KdPrint(("Maybe request from SRV. status=%08x path=%S\n", Irp->IoStatus.Status, fullPathName));
PsDereferenceImpersonationToken(lpToken);
Irp->IoStatus.Status = STATUS_STOPPED_ON_SYMLINK;
Irp->IoStatus.Information = 0;
return;
}
It very much looks like, that when you resolve symbolic links on local filesystems, there is no need to get an access token from
PsReferenceImpersonationToken(), and the code goes on and succeeds.
But when you are on a mapped network drive, PsReferenceImpersonationToken() will return a token, and from browsing the code I
strongly believe, that the author didn't want to bother with the returned token and always returns STATUS_STOPPED_ON_SYMLINK.
So an intentional stopper on mapped network drives.
But to tackle with access token is I guess standard coding for a experienced driver developer:
Check if we get an access token, and if yes then continue, and if no then return STATUS_STOPPED_ON_SYMLINK.
So in other words: Do not give up immediatley, but at least try to resolve the token, because it might be easy. Am I right?
What do I need: Help. I guess I can manage to compile the driver, but I do not have the experience to find the right lines of
code for this token access check.
The driver was written by Masatoshi Kimura, is freeware, and can be downloaded from http://homepage1.nifty.com/emk/symlink-1.06-src.zip
My tools are also freeware and are available under http://schinagl.priv.at/nt/ln/ln.html and use the driver.
Anyone willing out there to help two freeware projects?
Ciao and thanks
Hermann