> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
> Neil Wilson
> Sent: Friday, September 11, 2009 2:05 PM
> To: Rainer Gerhards
> Subject: Re: [Bug 407862] Re: [karmic] Messages not being sent to
> system logs
> 
> Rsyslogd can't run initially as non-root if it is going to listen on
> port 512 or directly access the kernel logs. It needs to open that
> first as root and then keep them open while dropping privileges. So
> we're still going to have to root drop problem regrettably. (I'm sure
> you already know that. I'm just pointing it out for the rest of the
> audience here).

Michael Biebl, the Debian Maintainer, suggested using capabilities to reduce
this need. I will look into this, but other than that I agree.


> Once you sort the code so that it goes to non-root early, then it will
> fail to open any file for which it doesn't have permissions and will
> create files with the correct ownership. I believe that is the right
> approach: rsyslog shouldn't be changing permissions on files.

full ack

> 
> The issue we have at the moment is two fold:
> 
> - firstly we either create root owned files, or open root owned files
> and then write to them for a bit until the privileges drop and the
> files are closed
> - secondly we don't get any decent error out of rsyslog reporting the
> 'Permission denied' issue on opening/reopening of the files.

I have seen some issue when I worked on the patch this morning. But this
issue was so far unreported. It looks like a regression, and I am not sure if
4.2.0 already has this problem.

> 
> As you probably already know the file access code could do with a bit
> of TLC. It doesn't report errors as well as it should.

large parts of the code have been rewritten in the current beta/devel
versions.

> If you drop root privileges early enough before any files are opened
> or created and report errors properly in the File code then everything
> else will follow.

Ah, OK, I see where you are coming from. So the files were initially created
by rsyslogd? I thought they were created by some other process. Mhhh... could
be. But in any case, the very simple cure with the current code base is to
specify the correct file owner right at the top of rsyslog.conf, so the files
will be created with the correct owner right from the beginning. Note that my
patch (and the patch posted here), assumes that the file owner was properly
configured. If there is no proper owner config, neither of the patches will
work. Thus I assumed this were no issue... 

> Note that we don't kick off root processes to write files; we kick
> them off to read privileged files for which there is no other
> alternative - the kernel dmesg output doesn't appear to have a
> permission entry that works properly for example, and of course
> network ports under 1024 need root permission. It might be possible to
> engineer rsyslogd so that it runs as two processes that talk to each
> other. One as root to read the network ports and the kernel with the
> other running as a normal user to do the normal syslog processing.

you can already do that, and it is my default suggested config for
security-sensitive environments. I think internally TCP connections are used
to combine the two, but other modes are also possible. 

But my reference was not to processes to read files, but to the process to
write files.

Rainer
> 
> 
> 2009/9/11 Rainer Gerhards <email address hidden>:
> > I couldn't agree more, and that is why I say that this work-around
> will
> > be broken once rsyslog's privilege drop code has been rewritten. As
> > stated in the wiki, the current solution is a quick and dirty one,
> > provided only because there seems to be some value in providing it
> over
> > not providing it.
> >
> > However, as far as this problem is concerned, this is not over root
> > access or non-root access. The issue is that rsyslogd should run as
> non-
> > root. Let's assume it finally has decent code to do that. Then it
> will
> > run, from the start on, as non-root. But then rsyslog.conf specifies
> > that rsyslogd shall write to files where it has no permissions. My
> point
> > is that either rsyslog.conf is invalid OR the files have been created
> > with wrong permissions. In any case, it is not something that rsyslog
> > can/should fix, because it is outside the scope of its configuration
> and
> > capabilities. I would consider it the wrong approach to create a root
> > child process just to write to some files, which apparently are set
> not
> > to be accessible for the daemon users. IMHO this is an inconsistent
> > system setup, and *that* root cause needs to be fixed.
> >
> > Rainer
> >
> > --
> > [karmic] Messages not being sent to system logs
> > https://bugs.launchpad.net/bugs/407862
> > You received this bug notification because you are a direct
> subscriber
> > of the bug.
> >
> 
> 
> --
> Neil Wilson
> 
> --
> [karmic] Messages not being sent to system logs
> https://bugs.launchpad.net/bugs/407862
> You received this bug notification because you are a direct subscriber
> of the bug.
> 
> Status in Rsyslog: Confirmed
> Status in “rsyslog” package in Ubuntu: Fix Released
> 
> Bug description:
> Ubuntu 9.10 Alpha3
> 
> 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.