[Bug 3662] Provide chrooted sftp users dedicated session log without /dev/log unix socket in users chroot jail (that does not work when chroot jail is shared between multiple sftp servers e.g. via NFS)

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Wed Feb 7 01:39:34 AEDT 2024


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

Miranda <daku8938 at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Enhance sftp-server with a  |Provide chrooted sftp users
                   |parameter to customize the  |dedicated session log
                   |name of the log device      |without /dev/log unix
                   |(currently fix /dev/log)    |socket in users chroot jail
                   |                            |(that does not work when
                   |                            |chroot jail is shared
                   |                            |between multiple sftp
                   |                            |servers e.g. via NFS)

--- Comment #8 from Miranda <daku8938 at gmx.de> ---
@Damien Very sad that the fix /dev/log name is burried so deep in the
code.

An alternative minimal-invasive solution would be to to allow to follow
symlink if /dev/log in user's chroot jail is a symlink to a local file.

Give the /usr/lib/sftp-server program a new parameter

-L <0=do not allow to follow /dev/log if it's a symlink out of jail
(default) | 1=follow if /dev/log is a symlink out of jail>

(so, this would be the same concept as now with the bind mount, only to
be a symlink, so the performance and scaling problem would be solved)

In my case that would be the symlink:

/var/data/chroot/<username>/dev/log -> /var/data/dev/<username>


Best way I could imagine would be to provide /usr/lib/sftp-server
program a new parameter

-L <user log file wit %u being username macro>

e.g. so one could set

"ForceCommand internal-sftp -L /var/log/sftp/%u.log"

I can understand that it is not easy for you to change something here,
but please also understand that we need a solution. It seems like we
are a really rare user that operates OpenSSH SFTP as a HA cluster
having the user's chroot shared via NFS, and therefore the user logging
with exclusive lock on /dev/log in chroot does not work. Otherwise this
isse must have been reportet already long time ago.

Any solution welcome, if we could only have one. Thanks

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.


More information about the openssh-bugs mailing list