Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386

2010-12-31 Thread Steven Chamberlain
Package: syslog-ng Version: 3.1.3-1 Severity: grave Tags: security Hello, On kfreebsd-i386, installing the syslog-ng package with its default configuration files, sets the permissions of system log files including /var/log/messages, daemon.log, auth.log and perhaps others to -rwsrwsrwt. This hap

Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386

2010-12-31 Thread Laszlo Boszormenyi
package syslog-ng tags 608491 + confirmed thanks On Fri, 2010-12-31 at 12:29 +, Steven Chamberlain wrote: > Package: syslog-ng > Version: 3.1.3-1 > Severity: grave > Tags: security > On kfreebsd-i386, installing the syslog-ng package with its default > configuration files, sets the permission

Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386

2010-12-31 Thread Laszlo Boszormenyi
On Fri, 2010-12-31 at 12:29 +, Steven Chamberlain wrote: > On kfreebsd-i386, installing the syslog-ng package with its default > configuration files, sets the permissions of system log files including > /var/log/messages, daemon.log, auth.log and perhaps others to > -rwsrwsrwt. This happens wh

Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386

2010-12-31 Thread Steven Chamberlain
On 31/12/10 13:46, Laszlo Boszormenyi wrote: > But an important note, for me it's slightly different. "Only" messages > and syslog are changed to chmod ; auth.log and daemon.log are not. Hi Laszlo, I think syslog-ng must wait for some data to be logged before it opens those files for writing,

Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386

2010-12-31 Thread Steven Chamberlain
Hi again, I think I've managed to find the responsible system call using ktrace. To begin with I set all of my log files as chmod 640, and then: # ktrace -f ktrace.log -d /usr/sbin/syslog-ng -- -F -p /var/run/syslog-ng.pid Ctrl-C or kill that after about a second or so, then: # kdump -f ktrace.

Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386

2010-12-31 Thread Steven Chamberlain
Hi, bits/typesizes.h reveals that mode_t is u16 on kFreeBSD, rather than u32 on Linux. So the dummy/rogue value of '-1' that file_perm or dir_perm are initialised to, would be treated as a valid mode 0x. u16 doesn't allow room for a dummy value any more, so I thought the cleanest fix would b

Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386

2010-12-31 Thread Steven Chamberlain
tag 608491 + patch done Hi again, I've managed to rebuild syslog-ng on kfreebsd-i386 with my previous patch applied to properly test it. syslog-ng now sets file permissions on log files appropriately to the configuration setting of perm(), or otherwise 0600 if it wasn't defined. The patched ver

Processed: Re: Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386

2010-12-31 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org: > package syslog-ng Limiting to bugs with field 'package' containing at least one of 'syslog-ng' Limit currently set to 'package':'syslog-ng' > tags 608491 + confirmed Bug #608491 [syslog-ng] syslog-ng: log file permissions dangerous on kfreebsd-i

Bug#608491: Problem & Fix (was: Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386)

2010-12-31 Thread Gergely Nagy
The problem is that chwon(fn, -1) works differently on Linux than on FreeBSD. Linux doesn't change the permissions if mode is -1, FreeBSD does. The workaround would be to test for -1 in syslog-ng and not call chmod in those cases. For the record, affile_open_file gets the same arguments even on L

Processed (with 5 errors): Re: Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386

2010-12-31 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org: > tag 608491 + patch Bug #608491 [syslog-ng] syslog-ng: log file permissions dangerous on kfreebsd-i386 Added tag(s) patch. > done Unknown command or malformed arguments to command. > Hi again, Unknown command or malformed arguments to command. >