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