https://bugzilla.mindrot.org/show_bug.cgi?id=3662 --- Comment #6 from Miranda <daku8938@gmx.de> ---
(In reply to Damien Miller from comment #3)
> you shouldn't need a /dev/log socket with internal-sftp, it logs via
> the privileged monitor sshd process that runs without chroot
Right, it seems like if sftp-server does not find the /dev/log in the
user's chroot jail (that is /var/data/chroot/<username>/dev/log
absolute path in my case), the sftp server (monitor) writes to global
/dev/log device (so absolute path ist /dev/log).
With that, yes, there would not be any NFS concurrent lock problem
anymore. We would have alle the log messages of all users together in
one local system's /dev/log device and could read it with syslog-ng via
the sftp-specific log facility set with e.g. "ForceCommand
internal-sftp -f LOCAL5".
But for each of our 1400 sftp customers we need to have a reliable
dedicated sftp log, for our support to be able to look for one specific
customer's sftp activity, therefore we would need to parse the global
log to filter each user's log lines and write those to a user specific
log file. The problem is, I think it is not trivial to make this
parsing reliable and robust, since we need to parse the process id
(sftp session), check which username that session belongs to and write
that log lines to the username specific log file. Of course, process
IDs are reused for different sessions, we have overlapping sessions of
the same user in the same time etc. A challenge would also be e.g. if
the user never logs out, and the log file rotates daily, so after one
day, the parser could not find any "session opened for local user xxx"
log lines anymore. And we need the user's log to be 100% reliable for
high service and support quality.
For that reason, I really would like to stay with each user having a
specific dedicated log device at the first point, because that is
simple, scaling and fast (real time result, no parser process in
between needed) and 100% guaranteed reliable and robust.
My suggestion for a solution:
-----------------------------
Give the /usr/lib/sftp-server program a new parameter
-L <custom log device name that is searched for underneath /dev>
For example one could set
"ForceCommand internal-sftp -L log1"
and then the sftp-server would look for a /dev/log1 in the user's
chroot jail and if it exists, write the user's log to that device.
In my case on the second sftp sftp server I would set
"ForceCommand internal-sftp -L log2"
Then of course the syslog-ng on the first sftp server would need to
listen to /dev/log1 and on the second server syslog-ng would need to
listen on /dev/log2 of every user). So, with that, this issue would be
solved.
Maybe, if sftp-server would not find the configured custom log file
(e.g. /dev/log1) in a user's chroot jail, it could try to log to
system's /dev/log file (so, absolute path /dev/log), so that would be
the old behavior. No strong opinion in that, though.
--
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