Re: packages using non-standard ports
On 02/08/14 19:17, Henrique de Moraes Holschuh wrote:
> On Sat, 02 Aug 2014, Josh Triplett wrote:
>> How easily could you teach syslog-nagios-bridge to listen on a UNIX
>> domain socket, instead of or in addition to a TCP socket? You could
>> then have it listen on /run/syslog-nagios-bridge by default, and have
>> rsyslog automatically forward messages there.
> Unless this socket is *never* going to need any sort of access control, rule
> zero for UNIX socket security applies: you must put it inside a directory.
> I.e. unless this socket always has to be accessible by everyone, don't put
> it directly in /run. Use something like /run/syslog-nagios-bridge/socket,
> and depend on the access permissions of /run/syslog-nagios-bridge/ to
> control access to the socket.
> That may well mean you need the directory just for the socket. If you have
> extra files that need different access restrictions, they'll have to go in a
> separate directory.
Using a UNIX socket involves:
- patching python-netsyslog to create the socket instead of binding to a
TCP port (this is not hard)
- using rsyslog's omuxsock module
Looking at that, it appears less flexible than TCP as the socket name is
defined globally, so if somebody else already writes to some socket,
maybe they can't have multiple output sockets? Or maybe that is just a
shortcoming in the documentation/example though?
It would also be necessary to check how rsyslog behaves when the socket
is not there (e.g. if rsyslog starts before syslog-nagios-bridge or if
syslog-nagios-bridge is restarted). Using TCP, rsyslog caches the
messages for peers that are temporarily offline.
However, I agree the UNIX socket is more flexible than hard-coding some
port number and it is also easier to align with current security
practices for log data (e.g. the socket would only be accessible to
root, just like /var/log/*)