FS#15787 - [syslog-ng] Refuses to write to files not owned as root
Attached to Project:
Arch Linux
Opened by Jason Sorensen (kovert) - Tuesday, 04 August 2009, 15:56 GMT
Last edited by Allan McRae (Allan) - Saturday, 15 August 2009, 03:52 GMT
Opened by Jason Sorensen (kovert) - Tuesday, 04 August 2009, 15:56 GMT
Last edited by Allan McRae (Allan) - Saturday, 15 August 2009, 03:52 GMT
|
Details
Description:
I believe this started after the first upgrade to 3.0.3-1. The errors began on the 31st after I rebooted. The behavior before 3.0.3 allowed files not owned as root to be written to. After the upgrade syslog-ng complains and refuses to write to the files. The daemon syslog-ng is running as root so I don't understand why it doesn't have permission. I have Zimbra installed and the log files aren't owned by root. If I delete the log file and restart syslog then syslog will recreate it with the owner zimbra and the group log with the permissions 640. It will actually write a few lines before the ownership is changed and then complain that it doesn't have permission. If I remove owner("zimbra") from the syslog-ng.conf file and delete the file it will write to the file without any errors since it gets recreated and is owned by root. I upgraded syslog to the latest version today and the problem still exists. Additional info: -rw-r--r-- 1 zimbra zimbra 0 2009-08-04 11:13 zimbra.log Aug 4 11:14:15 mycotoxin syslog-ng[25406]: Error opening file for writing; filename='/var/log/zimbra.log', error='Permission denied (13)' [2009-07-21 21:21] upgraded syslog-ng (3.0.1-6 -> 3.0.3-1) [2009-08-04 09:43] upgraded syslog-ng (3.0.3-1 -> 3.0.3-2) filter f_local0 { facility(local0); }; # zimbra destination zmail { file("/var/log/zimbra.log" owner("zimbra") ); }; # zimbra log { source(src); filter(f_mail); destination(zmail); }; # zimbra destination local0 { file("/var/log/zimbra.log" owner("zimbra") ); }; # zimbra log { source(src); filter(f_local0); destination(local0); }; # zimbra filter f_auth { facility(auth); }; # zimbra destination zmauth { file("/var/log/zimbra.log" owner("zimbra") ); }; # zimbra log { source(src); filter(f_auth); destination(zmauth); }; # zimbra Steps to reproduce: chown bin /var/log/everything.log /etc/rc.d/syslog-ng restart tail -100 /var/log/syslog.log You should see a permission denied as soon as something is written. |
This task depends upon
Closed by Allan McRae (Allan)
Saturday, 15 August 2009, 03:52 GMT
Reason for closing: Fixed
Additional comments about closing: syslog-ng-3.0.3-3 in [testing]
Saturday, 15 August 2009, 03:52 GMT
Reason for closing: Fixed
Additional comments about closing: syslog-ng-3.0.3-3 in [testing]
FS#13760)1) There is an option built in that allows you to specify the owner of the file when it is created.
2) The syslog daemon is running as root.
3) This used to work before the upgrade.
Isn't there a way you could tell it to write the zimbra log file as a differen user/group?
Also, I found this setting:
owner() - The default owner of output files. By default, syslog-ng changes the privileges of accessed files (e.g., /dev/null) to root.root 0600. To disable modifying privileges, use this option with the -1 value.
EDIT: Pasted group, meant to paste owner
http://www.balabit.com/dl/html/syslog-ng-v3.0-guide-admin-en.html/ch08s09.html
syslog-ng, is run as root, this is true, but drops many capabilities, a quick review have the correct capabilities (cap_dac_override, and others), but are not effective. (have +p and bot +ep) (see with getpcaps <pid>)
For workaround this, run syslog-ng with --no-caps or patch it.
I modified the syslog-ng, I think that this should be submitted to upstream so can review it.
Remamber: Please take care about my patch, it works, but is a "workaround".
[#1] https://bugzilla.balabit.com/show_bug.cgi?id=42
https://bugzilla.balabit.com/show_bug.cgi?id=52
capability management is kind of experimental in syslog-ng 3.0, we do not enable it in our
binary packages right now. but you are right, if cap management is enabled, syslog-ng loses
its CAP_DAC_OVERRIDE setting, thus it can only operate on files owned by root. If this is
not the case, it won't work.
So should we disable that in our builds for the time being