cygwin sftp chroot cannot view contents of bound mountpoint

Question

I'm trying to give user2 access only to his home directory and full permissions on /cygdrive/e. I created a Data/ directory within his $home, added a bind directive in /etc/fstab (see below), and issued a mount -a.

I've got cygwin installed and sshd running (OpenSSH_6.1p1). When connecting with ChrootDirectory enabled in an sftp subsystem, ~/Data appears to have no contents. Even if I change the permissions for /cygdrive/e recursively to 0777, the result is the same. With ChrootDirectory active for that user in sshd_config, no contents are displayed.

However, connecting using the same user account without changing any permissions, the contents of ~/Data is fully populated after I comment out the Subsystem section at the bottom of sshd_config and restart sshd.

So how can I grant this cat god-mode permission on /cygdrive/e without giving him the ability to browse any other part of the filesystem? What am I missing?

The bottom of my sshd_config is as follows:

Subsystem       sftp    internal-sftp
Match User user2
  ChrootDirectory /home/%u
  X11Forwarding no
  AllowTcpForwarding no
  ForceCommand internal-sftp

The only line in /etc/fstab reads as follows:

/cygdrive/e /home/user2/Data none bind,posix=0,user

Currently, recursive ownership of /cygdrive/e belongs to Administrators:Users. The user2 Windows account is a member of Users as well as Administrators. All directories have a mask of 0755. All files have a mask of 0644.

I'm not crazy about user2 having admin rights to the machine, but I'll deal with that later. One problem at a time.

score 3 · Answer 1 · edited Apr 13 '17 at 12:14

Answer

Unfortunately, this is not possible. Many elements conspire to defeat you at every turn.

Why not create a mountpoint within the jail?

Apparently mount in cygwin behaves much differently from in a POSIX operating system. In cygwin, mount is limited to the scope of the current logged on session. This means that if you mount a device as user1, then user2 will not have that mount available.

It does not matter whether the mount type is bind, a more traditional ntfs-type mount, or a cifs network share. No type of binding is persistent. Even if you mount --change-cygdrive-prefix /path/to/jail, the sftp users won't see it -- indeed, nor would other privileged users.

proof of scope of mount

OK, then, why not put the jail inside /cygdrive/e?

As the sftp client connection is made, /cygdrive/e doesn't exist yet. Even if it did, there's another problem. Keep in mind that every directory from stem to stern of /path/to/jail must be owned by root. Since /cygdrive is mounted at runtime for the user's session, the owner of /cygdrive is the current user. And chown root:whatever /cygdrive does nothing -- no error, but no effect either.

What about a host OS solution? Would a Windows hard link or a junction work?

Unfortunately, from the perspective of client interaction, mklink is just a fancy way of making shortcuts. It doesn't matter whether you're making a file or directory symlink, a hard link, or a junction. The sftp client sees them all as just icons with an arrow mklink doesn't fool the sftp client with its particular method of trickery.

Accepting defeat

There's simply no way to teach an internal-sftp chroot to understand cygwin's awkward imitation of mount. Others have tried, but even the experts are confounded.

Well, then, don't use internal-sftp. Make a wrapper script to perform a mount at connect.

This might be possible. I haven't tried it, because there seems to be no easy way for the wrapper to differentiate privileged from chroot-jailed user, and I still want to be able to browse the full filesystem with my own account. Besides, setting up a full chroot jail environment offends my delicate sense of aesthetic appeal. I'd rather the logged on user have fewer places to get lost. I prefer a low crap-to-content ratio, if that makes sense.

So what are you going to do?

On my Windows PC I shared the folders I want accessible to sftp. On a small Linux appliance PC, I mapped the appropriate cifs shares via autofs, as well as setting up delayed mount bindings in fstab, binding directories in the autofs mounts to mountpoints within an internal-sftp chroot jail. It works smashingly! The client connects to my Linux appliance to up/download files on my Windows shares. For the user, the whole thing is completely transparent. For me, the setup is tolerant of reboots and worry-free.

Perhaps this would be a good excuse for anyone in a similar situation to get a Raspberry Pi or a Plug PC of some sort and do the same.