Successfully created a chroot sftp user and his structure: nomad:~# grep prova /etc/passwd prova:x:1000:107:,,,:/:/bin/false nomad:~# grep ftponly /etc/group sftponly:x:107: nomad:~# less /usr/local/test_openssh/etc/sshd_config ... Subsystem sftp internal-sftp Match User prova ForceCommand internal-sftp ChrootDirectory /siuvar/chroots/prova/ AllowTcpForwarding no X11Forwarding no ... I already know it is not possible for the user prova to write directly into the chroot dir "prova" :-( in which I've created a subdir "www": drwxr-xr-x 9 root root 4096 2009-06-30 22:31 . drwxr-xr-x 3 root root 4096 2009-06-30 21:34 .. drwxr-xr-x 2 prova sftponly 4096 2009-06-30 22:07 www The bug: is always possible by prova user via FileZilla client to delete any "www" subdir if empty and owned by users other than prova. If the subdir contains root files (or files owned by users other than prova) the subdir is not deletable.
Ops! May not be a bug but a standard beheviour on ext3 fs! Solved changing: drwxr-xr-x 2 prova sftponly 4096 2009-06-30 22:07 www to: drwxrwxr-x 2 root sftponly 4096 2009-06-30 22:07 www
No. Also with this permissions drwxrwxr-x 2 root sftponly 4096 2009-06-30 22:07 www a root owned empty subdir of "www" may be erased by user "prova"
Huh, please learn more about UNIX/Linux DAC permissions. You need sticky bit set on the www directory if you don't want users delete each other's files.
(In reply to comment #3) > Huh, please learn more about UNIX/Linux DAC permissions. > > You need sticky bit set on the www directory if you don't want users > delete each other's files. Yes, I did the correct permission drwxrwxr-t 2 root sftponly 4096 2009-06-30 22:07 www and worked as in comment #1 but for some reason I checked later an old config and posted again. My apologise :-), thanx.
Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.