[Bug 3715] New: safely_chroot is a little too restrictive: noexec or nosuid should be enough

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3715

            Bug ID: 3715
           Summary: safely_chroot is a little too restrictive: noexec or
                    nosuid should be enough
           Product: Portable OpenSSH
           Version: 9.8p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: joshudson at gmail.com

Created attachment 3828
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3828&action=edit
most of a patch restoring old documented behavior -- needs autoconf
work

>From my perspective this is a regression, but it's a regression from a
far branch somewhere, not from a previous version of openssh. The
second blockquote here https://unix.stackexchange.com/a/396684 seems to
be quoting the manpage from the branch but I can't find its origin.

We have this working on our deployment today with a decode old
codebase; but in testing a replacement server closer to stock openssh
it doesn't work.

The general case is you want a lot of sftp users; each chrooted into
their own home directory, and each having write access to their own
home directory; where each can see no other.

Basically, there's no reason in particular this configuration shouldn't
work:

Subsystem sftp internal-sftp

Match Group filedrop
    ChrootDirectory %h
    AllowTCPForwarding no
    X11Forwarding no

where the home directories of all the users are under /u and /u is
mounted noexec.

I was pretty much able to just fix the problem on the first attempt
except for I got lost in autoconf; I have a patch available that still
needs to be edited so that autoconf knows what to do. (There's still
some systems lacking the statvfs() call.)

There's one weirdity I haven't been able to explain though. Why is
nodev (to be) required? It's not like an external filesystem; the user
can't *make* devices. But that's what the document says; so that's what
I put back.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.