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 protected]>: > 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 member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
