https://bugzilla.mindrot.org/show_bug.cgi?id=3662
Miranda <[email protected]> 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 <[email protected]> --- @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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
