> > This is not valid reasoning, as Eric Blake already pointed out you can > still access files outside of a chroot even if you're still going > through the Cygwin DLL by using Win32 style pathnames since Cygwin > passes those through untouched. Whether or not you can trick the sftp > code into letting such a filename through remains to be seen, but the > point here is that just because the access occurs via the Cygwin API > doesn't mean the chroot is absolute. >
I am just trying to be logical here. I am exporting only SFTP access to users. Well at least that's what I want, I don't know whether somehow user is able spawn another application via SSHD using something which I am not aware yet. This is one of my questions which hasn't been answered so far (what subsystems are handled internally by SSHD apart from shell and sftp?). So logically, with just SFTP available, what user can do is limited to basically; cd, mkdir, rmdir, get, put, rename, rm. Simply put, he can only manipulate files and directories. And if I understand correctly, one of the possible way for user to bypass check by Cygwin is to use Win32 reserved file names. identifying what filenames are reserved by Win32, this is what I've got (please complete it if I am missing something): Dos devices: CON, COMn, LPTn, AUX, PRN, NUL (n=0, 1, ...) Named Pipes: \\.\Pipe\foo Physical Driver: \\.\PhysicalDriveN (N=0, 1, ...) I tried the following commands from a jailed sftp session: sftp> get PRN Fetching /home/user/PRN to PRN Couldn't read from remote file "/home/user/PRN" : Failure sftp> put foo PRN Uploading foo to /home/Administrator/prn foo 100% 4 0.0KB/s 00:01 Couldn't write to remote file "/home/Administrator/PRN": Permission denied Invalid command. sftp> get CON Fetching /home/user/CON to CON Couldn't get handle: Permission denied sftp> put foo CON Uploading foo to /home/Administrator/CON Couldn't get handle: Permission denied sftp> get NUL Fetching /home/user/NUL to NUL *** successful transfer *** sftp> put NUL Uploading NUL to /home/Administrator/NUL NUL 100% 0 0.0KB/s 00:00 *** successful transfer *** sftp> get LPT1 Fetching /home/user/LPT1 to LPT1 Couldn't read from remote file "/home/user/LPT1" : Failure sftp> get //./Pipe/foo Couldn't stat remote file: No such file or directory File "//./Pipe/foo" not found. sftp> put foo //./Pipe/foo Uploading foo to //./Pipe/foo Couldn't get handle: No such file or directory sftp> get COM1 *** stuck *** So far, the only successful transfer is using NUL device (which is harmless) and the one which cause problem was accessing COM1. The client was stuck and I had to kill the SSHD daemon to restore it. If this is the only problem, I can remove all COMn from the host Windows. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/