Permission denied on specific operations when using symlink to network share

[sawo1337]

"OpenSSH for Windows 8.1.0.0"

Windows Server 2016 Datacenter

Client OperatingSystem Any

What is failing When using a symlink to a network share as ChrootDirectory, I can rename files, delete files, create empty files, but as soon as I attempt to append any data to the file I just created, I get permission denied. An empty file is created on the server, but no data is in it. I'm using domain users, they have full permissions over the network share, NTFS permissions on the network server, I can log in using the same user and create files just fine, but as soon I attempt the same using SFTP client, it fails with permission denied error. On the target server, I can see the correct user is attempting the operation, but for some reason, it fails. No failure is logged on the network share server, tried different network share server where everyone has full control, but still no go. It is interesting that during testing this worked for a brief moment, but then it never worked afterward. This is all with password authentication.

Config:

AllowGroups domain\sftpgroup AuthenticationMethods password ForceCommand internal-sftp ChrootDirectory C:\root\sftpnetworksharesymlink AllowTcpForwarding no PermitTunnel no GatewayPorts no

Expected output Files are uploaded by the logged-in user.

Actual output An empty file is created and then permission denied message is shown on the client.

[bagajjal]

Check https://github.com/PowerShell/Win32-OpenSSH/issues/1258

[sawo1337]

Thanks, I've seen this and this is where I started, but the issue for me is that even though this workaround works and I can create/delete/rename files and folders, I cannot append data to the files I've created. I do have proper permissions since I can manipulate files in ChrootDirectory that sits on a symlink to a network share, but I just can't append data to these files.

I've enabled a security audit on the NTFS folder where the network share lands via the symlink and I can see that the first event is access request:

Access Request Information:
	Transaction ID:		{00000000-0000-0000-0000-000000000000}
	Accesses:		READ_CONTROL
				SYNCHRONIZE
				WriteData (or AddFile)
				AppendData (or AddSubdirectory or CreatePipeInstance)
				WriteEA
				ReadAttributes
				WriteAttributes

This is all fine and well I believe, but the next audit events show where it fails:

An attempt was made to duplicate a handle to an object.

Subject:
	Security ID:		domain\thesftpuser
	Account Name:		thesftpuser
	Account Domain:		CORP
	Logon ID:		0x2C7E628

Source Handle Information:
	Source Handle ID:	0x1424
	Source Process ID:	0x4

New Handle Information:
	Target Handle ID:	0x155c
	Target Process ID:	0x4

The next two events are "The handle to an object was closed." - one from SYSTEM and another from the domain user who connected to the SFTP session initially. Looks like that duplicate handle fails and then the operation is canceled altogether.

Edit: I've tried entering PS session on the SFTP server with the SFTP user, went to the symlink SFTP root folder, created file and succeeded without any issues.

[Youbi42]

Hello, I have the exact same problem. Windows Server 2016. OpenSSH_for_Windows_8.0p1, LibreSSL 2.6.5

[sawo1337]

This appears to be a bug in the server, I still haven't found a solution as well.

[penicaudm]

Also having the same bug.

Windows Server 2016 Standard Core 10.0.14393 SFTP version 3 OpenSSH_8.1p for Windows

NTFS rights are correct, the user has correct permissions and can create / upload / delete stuff in a PS session or the Windows explorer.

[Marcel2]

I'm having the same problem. From a Windows perspective, openssh should run under an AD service account to access a network share. It appears that this is not intended with OpenSSH. I would be very happy to find a solution for this problem.

[ghost]

We are having the same issue. We had to develop a file sync job to circumvent this bug. Please do tell if we can do anything to help getting it fixed.

[sawo1337]

Looks like there is still no solution to this, which sadly makes the application useless to a lot of people.

[ghost]

Are anyone from the project receiving e-mails or notifications about this issue? I'm sorry i'm a bit new to Github issues. @maertendMSFT @manojampalam

This problem makes it impossible to have a non-hacked setup of an SFTP-server, where the files are located on another server/file cluster via smb/file shares.

[maertendMSFT]

Yes, we get notifications :) There can be some delay in responses/solutions based on current prioritization of Win32-OpenSSH.

@bagajjal , can you look at this issues again?

[aman6261]

New to github and unfortunately a negative first post -

my project has decided not to proceed with openssh due to the same limitation... we have a requirement where -

1. sftp client will connect to a SFTP server using key based authentication
2. After authentication, it will write files to chroot directory.. this chroot directory is basically a symlink to a NAS path....
3. Due to the limitation of openssh, it’s not possible to write to a symlink which has NAS reference, if chroot directory is a symlink.
4. As a work around, if I don’t set chroot directory for that sftp client user, that user is able to write/read/modify/delete to NAS location while accessing via symlink using password based authentication..
5. but it allows sftp user to access whole sftp server which is a security breach...
6. I am yet to test symlink (reference to NAS) with key based authentication if there is no chroot directory but since project has decided not to accept this risk, I might not get a chance to check via key based authentication...

But I will keep a track of this story.. hopefully will proceed with openssh once the fix is available...

thank you...

[malfuncion]

Just compiled the latest version from the repo and this issue still occurs in August of 2022. I tried earlier in the year and came across similar posts with this bug dating back to 2019. This issue unfortunately doesn't appear to be a priority and as another mentioned, makes this deployment useless on Windows for a lot of people.

We have unfortunately moved over to the SolarWinds SFTP server but it too has its own set of limitations- but not of the symlink variety.

[sawo1337]

We actually retested this just two weeks ago and nothing has changed in this regard. It has been long enough so we moved to a proper Linux solution which we managed to deploy in a couple of days. Kerberos domain authentication, network share access with chroot - everything that is not possible with this windows port, works perfectly under Linux. Not being able to chroot to a network location is a pretty serious flaw and makes this project useless to a lot of people.

[vthiebaut10]

@sawo1337 Can you test your scenario with the latest release of OpenSSH? I am able to repro the behavior you described on version 8.9, but the write operation works on version 9.2.

[maertendMSFT]

This issue was fixed in this PR: https://github.com/PowerShell/openssh-portable/pull/596

Let us know if you are able to repro this on the latest release.

[sawo1337]

@sawo1337 Can you test your scenario with the latest release of OpenSSH? I am able to repro the behavior you described on version 8.9, but the write operation works on version 9.2.

sure, I'll get this running on my test environment in the next couple of days, great to hear finally having a solution for it!

[sawo1337]

I can confirm this is now working as expected, creating a junction to UNC works fine!

[slonbalon]

Just confirm. Its work 🥇

[peteringemann]

Hi @vthiebaut10

Not to be rude or anything but I am still having the above mentioned problem using Microsoft OpenSSH 9.2.2.0 My scenario is just for testing at the moment but whenever it works I'll put it into production to be used as a message broker.

As for now I have, say 10 users getting their own ChrootDirectory E:\root\root%u Inside that %u folder I have a symbolic folder link (mklink \d) to a share located on another local harddrive (this will eventually be a UNC to a network share).

The point is that 1) all users have their own folder, and 2) they all share a folder from where they can all read, write etc.

When I log in and follow the symbolic link to the shared folder I can view files, I can rename but whenever I want to upload a file the file is created but it is a zero byte file. I get a permission denied from SFTP-client (FileZilla for testing) and eventually reports success.

Permissions are granted correctly - I've even, as for test, granted the Everyone account and also added the specific user and the group that I expect the users to be member of. If I set the ChrootDirectory to the shared folder I have no problem uploading. So I take that it is still a problem related to the symbolic link.

[vthiebaut10]

That behavior is expected if the symlink points to a folder outside of the new root. It should work with a network share though.

[peteringemann]

That behavior is expected if the symlink points to a folder outside of the new root. It should work with a network share though.

Because of security so that I don't upload a symbolic link pointing to a local folder like C:\Windows\System32 or whatever?

[rburgstaler]

That behavior is expected if the symlink points to a folder outside of the new root. It should work with a network share though.

This was what I experienced as well. I was able work around this by making a share to the same computer \\localhost\mysharelocationoutsideofnewroot and then making a symlink inside of the new root that points to \\localhost\mysharelocationoutsideofnewroot Feels like a dirty hack but does what is being discussed here.