I have set up a jailed dir using openssh (many thanks unSpawn).

However, when I login as a regular (specifically, jailed) user under sftp, I can remove anything I want in the chrooted dir. Even things owned by root outside of thier home dir.

If I log in using ssh, things are fine. Which really seems strange since I think sftp uses ssh.

I made sure to check the permissions on every dir and file in the chrooted dir. All are drwxr-xr-x 2 root root , or -rwxr-xr-x 1 root root, respectively.

I skimmed through the ssh_config and sshd_config, and nothing jumped out at me that would seem to indicate the sftp users get default ownership or write permission to everything.

I even made a couple of test as root, where I said # touch test1, then #chmod 600 test1, and the sftp user could delete it.

It must be that I'm not understanding put and get. If you can put to dir, that means you can write to it, right? So how can I allow users to put to one dir and not to another?

Any suggestions or reading would be appreciated.

Thanks.

If the user is jailed to there directory then how can they possibly delete files outside of there directory? In a chroot'ed environment those other directories do not even exist. When you chroot the user john to /home/john/./ his ROOT directory now becomes /john . There is no /home directory for John as far as he is concerned therefore he should not even be able to read any other directory besides /john and below.

I'm not saying that your a liar. I'm just wondering if sftp does not behave like ssh does in a chrooted environment. Also you are right about the 'put' command. Put is uploading a file and get is downloading a file. Usually when a user, who is allowed to upload files, goes to upload lets say test.txt and there is an existing test.txt file owned by someone else you will get a permissions error.

Strange days indeed...Most peculiar mama

Thanks for the reply -

What I meant was that the user has a /chrootedDir/home/someUser dir, and he can remove files above his home dir, but no, not outside the chrootdir. He's still locked in there, it's just that he has perms where he shouldn't.

With ssh, it's fine, but with sftp he can do whatever - in that chrooted dir.

Thanks

Aha I see. So the user is not actually chrooted to /someUser but rather chrooted to /chrootedDir . Why not chroot them to /someUser?

I'm sorry if I am asking silly questions here but I'm trying to get a feel for whats going on. You may hit me with a stick if I get out of line.

No stick necessary, I'v been hit with it too many times.

I wanted to share mp3s with some friends. So I figured that I would chroot some dir like so:

/ (chrooted root)
/bin /etc /mp3s /home
/home/someUser

This way I figured that they could get mp3s but not remove them, since they would only have perms to read in the mp3 dir. They could put files to their home dir since they would own that.

If there is an easier way to do it please let me know.

Thanks again.

I have a similar problem, see below. Do you ever resolve your issue with ssh2?

I have set up ftp server using guest accounts with their own jail space. No problem. I want to take the additional step of encrypted ftp sessions using this WU-FTP server with SSH2 along with a SSH2 ftp client. I'm testing the client using Win-SCP (for sftp or scp'ing). This is on Red Hat 8.0. (I removed vsftp that's there by default then installed wu-ftp since it's more clear how to set up guest accounts).

I can get the ssh2 client to connect with the ftp server, but only if I use /bin/bash for the user in /etc/passwd rather than /bin/true or ftponly. When I use /bin/bash Win-SCP will let me connect but I'm no longer constrained to my chroot'd directory like I would be with normal ftp and a guest account. I can go anywhere. If I use /bin/true for the guest account then Win-SCP errors on the connection. I assume I shouldn't give the scp client a normal shell program.

Is there a patch for WU-FTP to make this work or do I need to have something related to ssh2 in /etc or /bin or /lib in the users chroot'd directories? Permissions problem? I'm grasping for straws on this one..... any help is appreciated.

I fixed my problem by removing a sticky bit that was set on sftp-server file in the jailed dir.