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).

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.

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.

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.

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.

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.


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