[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Review request: syslog-ng (syslog replacement daemon)



On Sat, 2005-05-07 at 19:26 +0100, Jose Pedro Oliveira wrote:
> > On Sat, 2005-05-07 at 01:29 +0100, José Pedro Oliveira wrote:
> >>   * Changes a file from another package
> >>     (/etc/logrotate.d/syslog from the sysklogd rpm)
> >
> > Better to figure out how to generalize this.  See my later mail.
> 
> Don't know how to do it without using alternatives.  The best solution
> I came up with was to comment the /etc/logrotate.d/syslog lines
> using triggers.
> (previous comments in https://bugzilla.fedora.us/show_bug.cgi?id=1332)

The only difference between the two files right now is what pid file
they cat to figure out what service to restart.  Using a trigger to
comment all of the sysklogd package's version of this file is *BROKEN*
as just because a package is installed, doesn't mean it's being used.
Not to mention that the trigger strikes me as being relatively prone to
causing problems down the line.

As far as generalizing it, you could do this with a relatively trivial
change to the initscript.  In the start/stop, create and remove a
symlink of /var/run/syslog.pid that points to the syslog-ng pidfile.
Sure, it's a bit hacky, but it's better than sed'ing provided config
files all the time.

> >>   * currently it doesn't change the use_syslogng SELinux boolean
> >
> > I don't see any other packages doing anything like this at the moment,
> > and I'm not entirely sure how I feel about it.[1]  Looking at what the
> > boolean allows, I think that some of them at least are valid in the case
> > of sysklogd where you're using a remote syslog server.  cc'ing Dan to
> > see if he has an opinion here.
> 
> As the use_syslogng SELinux boolean is for syslog_ng, I don't see
> any problem in enabling/disabling it using the post scripts
> (see the message in trhe fedora-packaging mailing list).

Sometimes, the right answer to how to package a piece of software
includes getting other things in the distribution fixed.  And in this
case, I'm not convinced that syslog-ng's basic needs shouldn't be
covered by the standard syslog policy already, although there may be
gaps or bugs which should legitimately be looked at.  Let's look at the
things which the boolean allows:

  if (use_syslogng) {
  # Allow access to /proc/kmsg for syslog-ng
  allow syslogd_t proc_t:dir search;
  allow syslogd_t proc_kmsg_t:file { getattr read };

It looks like klogd uses /proc/kmsg by default for accessing kernel
messages, so why should this be covered under the boolean?  

  allow syslogd_t kernel_t:system { syslog_mod syslog_console };
  allow syslogd_t self:capability { sys_admin chown fsetid };

This looks like it's already allowed for klogd

  allow syslogd_t var_log_t:dir { create setattr };

sysklogd would need this functionality as well if it is allowed to
create arbitrary, not existing already log files.

  allow syslogd_t syslogd_port_t:tcp_socket name_bind;

You want to allow this for remote logging with sysklogd as well

  allow syslogd_t rsh_port_t:tcp_socket name_connect;

Not clear at all one why syslog-ng would need access to bind to the rsh
socket.  Source grepping a bit shows that it's being used for network
logging.  Aside from the brokenness of re-using a standard port, having
people be aware of the need to allow the operation if they configure
syslog-ng in this fashion doesn't strike me as a bad idea.

Jeremy


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]