https://bugzilla.mindrot.org/show_bug.cgi?id=3662
--- Comment #6 from Miranda <daku8...@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