[Bug 407862] Re: Messages not being sent to system logs
Bug Watch Updater
407862 at bugs.launchpad.net
Thu Aug 11 08:08:08 UTC 2011
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
Foundations Bugs, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/407862
Title:
Messages not being sent to system logs
Status in Rsyslog:
Fix Released
Status in “rsyslog” package in Ubuntu:
Confirmed
Bug description:
First reported on Ubuntu 9.10 Alpha3
It affects Ubuntu 10.04 Lucid Lynx Final Release, too.
rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="2296"
x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type
'lightweight'.
After the above message in syslog no more messages are sent to any
system logs. Plugging and unplugging an usb device produce no
messages, although the device is mounted an works fine. Also, nothing
is produced by the logger command.
The problem occurs in a desktop and in a VirtualBox virtual machine.
It occurred soon after karmic alpha 3 installation and persisted after
installing all available updates in both environments.
I'm attaching a typical syslog.
To manage notifications about this bug go to:
https://bugs.launchpad.net/rsyslog/+bug/407862/+subscriptions
More information about the foundations-bugs
mailing list