Currently, sshd requires the chroot directory to be owned by root. This
makes it impossible to chroot users into their own home directory, which
would be convenient for sftp-only users. Is there a particular reason
why, in safely_chroot() in session.c,
if (st.st_uid != 0 || (st.st_mode & 022) != 0)
fatal("bad ownership or modes for chroot "
"directory %s\"%s\"",
cp == NULL ? "" : "component ",
component);
can't be changed to
if ((st.st_uid != 0 && st.st_uid != uid) ||
(st.st_mode & 022) != 0)
fatal("bad ownership or modes for chroot "
"directory %s\"%s\"",
cp == NULL ? "" : "component ",
component);
?
DES
--
Dag-Erling Sm?rgrav - des at des.no
On Tue, Feb 21, 2012 at 12:40:31PM +0100, Dag-Erling Sm?rgrav wrote:> Currently, sshd requires the chroot directory to be owned by root. This > makes it impossible to chroot users into their own home directory, which > would be convenient for sftp-only users. Is there a particular reason > why, in safely_chroot() in session.c, > > if (st.st_uid != 0 || (st.st_mode & 022) != 0) > fatal("bad ownership or modes for chroot " > "directory %s\"%s\"", > cp == NULL ? "" : "component ", component);Most likely, this was made to ensure that the chroot directory itself is not writable and cannot be made writable by the user, to avoid various kinds of attacks. -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120221/2ff98642/attachment.bin>
Angel Gonzalez wrote:> Just one example. > If the user is the owner of /, he could move away /etc and replace it > with its own one, providing a /etc/passwd under its control. > > You may think a user-owned chroot is not a problem for your setup, and > it may not be, or there may be a way you don't yet known (or opened by a > config change). Having a root-owned / is *much* safer.I think that most used configuration of this chrooting is for sftp-only users. With this kind of config it is not a problem if /user creates etc in his home directory. Match Group sftp-only AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftp ChrootDirectory %h At least documentation should have note, that this reasonable looking configuration is not valid. Or if devs think that this shouldn't be allowed by default. Maybe they can add a configuration entry "TrustMeIKnowWhatIAmDoing yes" to make this configuration possible. (Currently I must use proftpd with sftp module, but I would like to use opensshd so there is only one software to handle both, file transfers and remote shells) -- Ari Saastamoinen