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.log -m 4096 -n This happens for each log file when first written to -- it is opened for writing (requesting mode 0xffff if the file doesn't exist), then chown'd/chgrp'd, and fchmod is called to ensure mode 0xffff: 1384 syslog-ng CALL open(0x80b1ae8,0x8205,0xffff) 1384 syslog-ng NAMI "/var/log/syslog" 1384 syslog-ng RET open 0x7 1384 syslog-ng CALL fcntl(0x7,0x1,0) 1384 syslog-ng RET fcntl 0 1384 syslog-ng CALL fcntl(0x7,0x2,0x1) 1384 syslog-ng RET fcntl 0 1384 syslog-ng CALL fchown(0x7,0,0xffffffff) 1384 syslog-ng RET fchown 0 1384 syslog-ng CALL fchown(0x7,0xffffffff,0x4) 1384 syslog-ng RET fchown 0 1384 syslog-ng CALL fchmod(0x7,0xffff) 1384 syslog-ng RET fchmod 0 Wherever affile_open_file is called, it seems the mode parameter is initialised to -1 unless changed somewhere else in the code. Then it's tested in affile_open_file to see if it's >= 0. Could the size or signedness of mode_t be different on FreeBSD to Linux, resulting in the 0xffff? Regards, -- Steven Chamberlain [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
