On 7/24/2017 8:39 PM, Nico Kadel-Garcia wrote:> > Why are the targets of the hardlinks evaporating on rebooting? Is that > a FreeBSD'ism?Its when syslogd stops/starts. The hardlinks need to be recreated for some reason. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/
On 2017-07-25 at 09:31 -0400, Mike Tancsa wrote:> On 7/24/2017 8:39 PM, Nico Kadel-Garcia wrote: > > Why are the targets of the hardlinks evaporating on rebooting? Is that > > a FreeBSD'ism? > > Its when syslogd stops/starts. The hardlinks need to be recreated for > some reason.Because /dev/log is a symlink to /var/run/log which is a Unix-domain socket, created by whatever listens for connections. You'll want to use syslogd_flags="..." in /etc/rc.conf to add a bunch of <-l location> pairs. Or create a new rc.d script to create the hardlinks if you're wedded to that, and use the rcorder keywords to have ssh depend upon it, etc. Honestly, I'd start looking instead at having syslogd listen on a UDP socket on a non-routed address and send to that locally instead. See the "-a" option to syslogd, although contrary to docs my past experience has suggested that -a can't be repeated. -Phil
Phil Pennock writes:> On 2017-07-25 at 09:31 -0400, Mike Tancsa wrote: > > On 7/24/2017 8:39 PM, Nico Kadel-Garcia wrote: > > > Why are the targets of the hardlinks evaporating on rebooting? Is that > > > a FreeBSD'ism? > > > > Its when syslogd stops/starts. The hardlinks need to be recreated for > > some reason. > > Because /dev/log is a symlink to /var/run/log which is a Unix-domain > socket, created by whatever listens for connections. > > You'll want to use syslogd_flags="..." in /etc/rc.conf to add a bunch of > <-l location> pairs. Or create a new rc.d script to create the > hardlinks if you're wedded to that, and use the rcorder keywords to have > ssh depend upon it, etc. > > Honestly, I'd start looking instead at having syslogd listen on a UDP > socket on a non-routed address and send to that locally instead. See > the "-a" option to syslogd, although contrary to docs my past experience > has suggested that -a can't be repeated.What about trying to pass the fd directly, where appropriate, i.e. 1) the subcomponent supports it to use syslog that way, 2) there is no fork/chroot involved that may make it hard to know, what the file descriptors were for and 3) there are no additional security risks associated with that behaviour. In remaining cases, where subcomponent would support that, define some environt variable, e.g. "_SSH_SYSLOG_TARGET_SPEC", which is "fd:[num]" for the most simple case, other might follow, perhaps "udp:[ip]:[port]" or "scm-rights:[receiver-fd]"? That could be very generic, also supporting SSH subcomponents invoked via "execve". Subcommands (or wrappers) may even use the variable to create hardlinks or forwarders before invoking the final command, so that they do not require SELinux/AppArmor and alike to give them privileges to do so. hd
On 7/25/2017 7:21 PM, Phil Pennock wrote:> Honestly, I'd start looking instead at having syslogd listen on a UDP > socket on a non-routed address and send to that locally instead. See > the "-a" option to syslogd, although contrary to docs my past experience > has suggested that -a can't be repeated.How do I get sshd to send via UDP to syslogd ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/