Review request: syslog-ng (syslog replacement daemon)

[José Pedro Oliveira]

Daniel J Walsh wrote:
> Jose Pedro Oliveira wrote:
> 
>>> 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.
>>>   
>>
>>
>> Can we expect that no changes are made to the syslog logrotate file?
>>
>> Sure it isn't the best solution but it appears to be the one that
>> is less harmful.  The triggers are only activated during install
>> and removal of sysklogd or syslog-ng.
>>
>>  
>>
>>> 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.
>>>   
>>
>>
>> It doesn't work for the following cenario:
>>  1) FC system with sysklogd
>>  2) install syslog-ng
>>  3) stop syslog
>>  4) start syslog-ng
>>  5) remove sysklogd
>>  => no logrotate file (!)
>>
>> Shouldn't the symlink idea be expanded to "alternatives" ?
>>
>>  
>>
>>>>>>  * 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:
>>>   
>>
>>
>> This is a moving target and I am a newbie when it comes to SELinux.
>> But in FC3 you wouldn't be able to start syslog-ng without (most of) the
>> following rules:
>>
>>     ...
>>     bool use_syslogng false;
>>
>>     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 };
>>     allow syslogd_t kernel_t:system { syslog_mod syslog_console };
>>     allow syslogd_t self:capability { sys_admin chown fsetid };
>>     allow syslogd_t var_log_t:dir { create setattr };
>>     }
>>
>> Source:
>>  RPM: selinux-policy-targeted-sources-1.17.30-2.96
>>  File: /etc/selinux/targeted/src/policy/domains/program/syslogd.te
>>
>> Hoping that Dan Walsh will answer the following questions:
>>
>>  
>>
>>>  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
>>>
>>
>> jpo
>>  
>>
> I am removing the boolean from prolicy.

Dan,

Will you also backport it to FC3 (and RHEL)?

TIA,
jpo
-- 
José Pedro Oliveira
* mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo *
* gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20050509/be9a876d/attachment.sig>