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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Allan McRae (Allan)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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]
Comment by Glenn Matthys (RedShift) - Tuesday, 04 August 2009, 16:31 GMT
Please attach your complete syslog-ng.conf.
Comment by Jason Sorensen (kovert) - Tuesday, 04 August 2009, 16:43 GMT
Here it is.
Comment by Jason Sorensen (kovert) - Tuesday, 04 August 2009, 16:44 GMT
The file has been modified since I submitted the bug report to work around this issue.
Comment by Aaron Griffin (phrakture) - Tuesday, 04 August 2009, 19:24 GMT
Can you explain how you "worked around" the issue? It's entirely possible the workaround is the way it's intended
Comment by Roman Kyrylych (Romashka) - Tuesday, 04 August 2009, 19:28 GMT
Either this is upstream change in behaviour or this is caused be removal of uid.patch (which was added to fix  FS#13760 )
Comment by Jason Sorensen (kovert) - Tuesday, 04 August 2009, 22:56 GMT
The work around to the issue was to change the owner and group (root/zimbra) of the file and change the permissions to 664. This issue doesn't make any sense because...

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.
Comment by Aaron Griffin (phrakture) - Tuesday, 04 August 2009, 23:08 GMT
Looks like 3.0.2 had some user/group related changes: http://www.balabit.com/downloads/files/syslog-ng/open-source-edition/3.0.3/changelog-en.txt

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
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 04 August 2009, 23:22 GMT
@Roman: uid.patch (logic "not" bug) was removed because is already in the syslog-ng code.

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.
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 05 August 2009, 01:57 GMT
Searching in the bugzilla i found some relevant report [#1]
Remamber: Please take care about my patch, it works, but is a "workaround".

[#1] https://bugzilla.balabit.com/show_bug.cgi?id=42
Comment by Jason Sorensen (kovert) - Thursday, 06 August 2009, 17:23 GMT
I've opened a bug upstream on this issue. I'm also using the --no-caps now as a workaround until this gets fixed. I haven't submitted your patch but I didn't want to do that on your behalf.

https://bugzilla.balabit.com/show_bug.cgi?id=52
Comment by Allan McRae (Allan) - Monday, 10 August 2009, 17:36 GMT
From https://bugzilla.balabit.com/show_bug.cgi?id=42:

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
Comment by Aaron Griffin (phrakture) - Monday, 10 August 2009, 20:06 GMT
That sounds fine to me. If you do get to updating this, please add this text or a link here as a comment, so it's more obvious we need to re-check this in the future

Loading...