My strace revealed that sshd was indeed attempting to open this socket and failing. I can see where if a user can inject into sshd that injecting into rsyslog would be trial for this person.
I don't fully understand the ramifications of extra code lying around to do things like: 1. Test for the existence of this socket. a. Act on config option enabling/disabling this. 2. Test for the existence of a /var/log folder or /var/log/auth.log file. a. Act on config option enabling/disabling this. Though the current code might not have anything wrong with it, AFAIK. If by default this file should not exist then there should be a config option set to disable it's use, with instructions on enabling syslog for testing. Perhaps this should be something only done in testing and should be disable by default. If one wanted a filtering proxy to be vary strict about the messages passed through this socket, then perhaps the solution is for sshd to provide such a proxy. This way messages could be limited to only the messages sshd itself would generate. -- Syslog socket missing from chroot. https://bugs.launchpad.net/bugs/582443 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
