Dear Developers, I would like to report two wrong behaviors of syslog-ng. I have received them while running the 2.1.alpha1 version, but from the GIT repository I see, it has not been reported nor fixed yet: 1) Possible problems in destination macro $PROGRAM I use macro $PROGRAM in some destination file name templates to better identify source messages. Unfortunately, sometimes the $PROGRAM macro in syslog message is filled with file name with full path. (Like /usr/bin/xxxxx.) This leads to the situation that syslog-ng tries to write to the complete different path than expected. And depending on the "create_dirs" option, new directories can be also created. Generically we can say, there is a problem that invalid unix filename/filepath characters can be passed to syslog and create a technical or security issue. (It is not only a problem of / slash, but any special unix character like . or ~ can change the path meaning.) I do not have any "best" solution now to offer, but I would like to ask you to validate this behaviour and extended the design so it is protected against such unexpected destination path manipulation. 2) Unexpected initialization of followed file sources I run a special instance of the syslog-ng under non-root configuration. It is started as root but with a "-u syslogng" option to switch to other user. And it is used to follow some file sources to be transferred to the central log server. It works fine, but only until the log is rotated in a wrong way. Let's explain: The log file's permissions has to be changed manually always after the rotation, to be readable by other users. This is my part, but for some reason, I have had an error there and I have received this scenario: - Initial status: the log permissions are private, the syslog-ng is unable to read the log -> this is expected. - I have restarted the syslog-ng instance due some reconfiguration -> OOPS, it has found and opened the -> this is unexpected! - The log is followed successfully, even with private permissions! - But, only until it is rotated again - I expect the file handle is lost finally So from my view: When a syslog-ng with -u option starts, it first opens all logs as root and after that it switches its effective UID:GID as required. This is nice feature, but a little bit unexpected. I would like to ask you if you can again check the initialization part of syslog-ng and clean the design, so it either: - always opens every (file) source under the non-root user (more secure, but worse for me) - or always re-opens the followed (file) sources with original higher root privileges (less secure, but nice and easier for me to read private application logs) Thank you in advance. Best Regards, Pavel