Launchpad has imported 7 comments from the remote bug at http://bugzilla.adiscon.com/show_bug.cgi?id=150.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-08-31T18:42:23+00:00 Michael Terry wrote: In Ubuntu, we use the $PrivDropToUser and $PrivDropToGroup to reduce rsyslog privileges. However, this in practice means that we need to also set $FileOwner to the same values and make sure that all existing output log files are already set to the right values (since FileOwner only applies to new files). If we don't do this, a HUP stops output, since rsyslog won't be able to open its own output files. I like how when PrivDropToUser is enabled, a HUP is automatically forced to be lightweight. Could something similar be done here? Where if the user enables PrivDropToUser, FileOwner gets set to the same value. Though, whether this needs to be done really depends on FileCreateMode, so maybe forcing it doesn't make sense after all. Additionally, could a configuration value like $FileChown (bool) be added? This would tell rsyslog to chown all output files upon open, if they're new or old. This could also be forced on when PrivDropTo* is used, modulo the FileCreateMode comment above. In the meantime, I can just patch the Ubuntu code to always chown, without the benefit of a config value. Reply at: https://bugs.launchpad.net/rsyslog/+bug/407862/comments/25 ------------------------------------------------------------------------ On 2009-09-01T12:32:16+00:00 Rgerhards-j wrote: I currently have no time to do that, but it looks interesting. Could you provide me the Ubuntu patch you have on your mind? I could probably quickly integrate it and bind it to a config statement (no promise, though ;)). Reply at: https://bugs.launchpad.net/rsyslog/+bug/407862/comments/27 ------------------------------------------------------------------------ On 2009-09-08T19:34:09+00:00 Michael Terry wrote: The change I made was really trivial -- just moved the chown call outside the 'does the output file already exist' check (see https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/407862 for gory details): Index: rsyslog-4.2.0/tools/omfile.c =================================================================== --- rsyslog-4.2.0.orig/tools/omfile.c 2009-08-31 14:47:37.000000000 -0400 +++ rsyslog-4.2.0/tools/omfile.c 2009-08-31 14:48:30.000000000 -0400 @@ -421,6 +421,7 @@ */ pData->fd = open((char*) newFileName, O_WRONLY|O_APPEND|O_CREAT|O_NOCTTY|O_CLOEXEC, pData->fCreateMode); + } if(pData->fd != -1) { /* check and set uid/gid */ if(pData->fileUID != (uid_t)-1 || pData->fileGID != (gid_t) -1) { @@ -438,7 +439,6 @@ } } } - } finalize_it: /* this was "pData->fd != 0", which I think was a bug. I guess 0 was intended to mean * non-open file descriptor. Anyhow, I leave this comment for the time being to that if Reply at: https://bugs.launchpad.net/rsyslog/+bug/407862/comments/30 ------------------------------------------------------------------------ On 2009-09-11T08:35:33+00:00 Rgerhards-j wrote: I have reviewed the details and the patch. I like the overall idea, but the patch is intrusive in that it changes existing expected behavior. I think it is not a good idea to unconditionally reset file owners if previous versions did not do that. So I will create a new config statement that enables this functionality, being off by default. Reply at: https://bugs.launchpad.net/rsyslog/+bug/407862/comments/31 ------------------------------------------------------------------------ On 2009-09-11T08:48:02+00:00 Rgerhards-j wrote: I think there are also some subtle issues with the patch. It does not address the situation that someone changes the ownership *after* rsyslogd has started. Let's, for example, consider a log rotation script. - rsyslog is started - ownership is changed - privileges dropped - log rotation (lr) script starts - lr removes files - lr creates new files with root:adm (or whatever else) - lr HUPs rsyslogd - rsyslogd closes files - rsyslogd tries to open files - rsyslogd tries to change ownership --> fail as we are non-root now - file open fails So while this fix is definitely useful, it does not - and conceptually can not - address these issues. Actually, I consider the those parts of the system that create the wrong ownership to be broken. So what the patch actually tries to fix something outside of the scope of rsyslog. Again, I think it is useful, but not as a real cure but only as an aid to reduce the effects of some other, wrong actions. I assume that it will work most of the time. However, once the $PrivDrop... code is refactored, this patch will no longer work, because then privileges will be dropped before any action is performed, and thus we will no longer be able to chown files that do not belong to the user rsyslogd is configured to run under. So it probably is a good idea to look at the rest of the system. Reply at: https://bugs.launchpad.net/rsyslog/+bug/407862/comments/32 ------------------------------------------------------------------------ On 2009-09-11T09:35:23+00:00 Rgerhards-j wrote: Added new directive $omfileForceChown to force the chown - as per restrictions laid out in my previous comment. Will be part of 4.7.0 and 5.3.0. Fix at: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=bfac3c68f47b8769b0936fb80eeea8880793fd2d Reply at: https://bugs.launchpad.net/rsyslog/+bug/407862/comments/34 ------------------------------------------------------------------------ On 2011-08-10T10:28:21+00:00 Rgerhards-j wrote: FYI: rsyslog v6.3+ will have "proper" priv drop code. That means the somewhat dirty "Ubuntu file permissions fix" will no longer work for the reasons stated in this tracker. Note that this fix actually worked because it escaped privilege drop, something definitely not desirable. Reply at: https://bugs.launchpad.net/rsyslog/+bug/407862/comments/69 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/407862 Title: Messages not being sent to system logs To manage notifications about this bug go to: https://bugs.launchpad.net/rsyslog/+bug/407862/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
