[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Sven Vermeulen]

Some applications that run within the user domain send messages to the syslog
daemon (for instance through the syslog() function). This patch allows the
userdomain to write to the devlog_t socket and interact properly with the
syslog daemon.

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 policy/modules/system/userdomain.if |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
index c6d3cc8..17abfcf 100644
--- a/policy/modules/system/userdomain.if
+++ b/policy/modules/system/userdomain.if
@@ -965,6 +965,8 @@ template(`userdom_unpriv_user_template', `
 	# cjp: why?
 	files_read_kernel_symbol_table($1_t)
 
+	logging_send_syslog_msg($1_t)
+
 	ifndef(`enable_mls',`
 		fs_exec_noxattr($1_t)
 
-- 
1.7.3.4

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Christopher J. PeBenito]

On 08/23/11 06:57, Sven Vermeulen wrote:
> Some applications that run within the user domain send messages to the syslog
> daemon (for instance through the syslog() function). This patch allows the
> userdomain to write to the devlog_t socket and interact properly with the
> syslog daemon.

Do you have some examples?  My initial reaction is definitely not
merged, as I don't want users to be able to flood the system logs.


> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>  policy/modules/system/userdomain.if |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
> index c6d3cc8..17abfcf 100644
> --- a/policy/modules/system/userdomain.if
> +++ b/policy/modules/system/userdomain.if
> @@ -965,6 +965,8 @@ template(`userdom_unpriv_user_template', `
>  	# cjp: why?
>  	files_read_kernel_symbol_table($1_t)
>  
> +	logging_send_syslog_msg($1_t)
> +
>  	ifndef(`enable_mls',`
>  		fs_exec_noxattr($1_t)
>  


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Dominick Grift]

On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
> On 08/23/11 06:57, Sven Vermeulen wrote:
> > Some applications that run within the user domain send messages to the syslog
> > daemon (for instance through the syslog() function). This patch allows the
> > userdomain to write to the devlog_t socket and interact properly with the
> > syslog daemon.
> 
> Do you have some examples?  My initial reaction is definitely not
> merged, as I don't want users to be able to flood the system logs.

I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?

> 
> 
> > Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> > ---
> >  policy/modules/system/userdomain.if |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
> > index c6d3cc8..17abfcf 100644
> > --- a/policy/modules/system/userdomain.if
> > +++ b/policy/modules/system/userdomain.if
> > @@ -965,6 +965,8 @@ template(`userdom_unpriv_user_template', `
> >  	# cjp: why?
> >  	files_read_kernel_symbol_table($1_t)
> >  
> > +	logging_send_syslog_msg($1_t)
> > +
> >  	ifndef(`enable_mls',`
> >  		fs_exec_noxattr($1_t)
> >  
> 
> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110824/b2a56548/attachment.bin 

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Christopher J. PeBenito]

On 08/24/11 09:15, Dominick Grift wrote:
> On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
>> On 08/23/11 06:57, Sven Vermeulen wrote:
>>> Some applications that run within the user domain send messages to the syslog
>>> daemon (for instance through the syslog() function). This patch allows the
>>> userdomain to write to the devlog_t socket and interact properly with the
>>> syslog daemon.
>>
>> Do you have some examples?  My initial reaction is definitely not
>> merged, as I don't want users to be able to flood the system logs.
> 
> I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?

Thats a different domain.  I'm speaking of unpriv user domains user_t,
staff_t, etc.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Dominick Grift]

On Wed, Aug 24, 2011 at 09:41:10AM -0400, Christopher J. PeBenito wrote:
> On 08/24/11 09:15, Dominick Grift wrote:
> > On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
> >> On 08/23/11 06:57, Sven Vermeulen wrote:
 ... snip ... 
> > I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
> 
> Thats a different domain.  I'm speaking of unpriv user domains user_t,
> staff_t, etc.

Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.


> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110824/5533363b/attachment.bin 

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Christopher J. PeBenito]

On 08/24/11 09:51, Dominick Grift wrote:
> On Wed, Aug 24, 2011 at 09:41:10AM -0400, Christopher J. PeBenito wrote:
>> On 08/24/11 09:15, Dominick Grift wrote:
>>> On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
>>>> On 08/23/11 06:57, Sven Vermeulen wrote:
>  ... snip ... 
>>> I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
>>
>> Thats a different domain.  I'm speaking of unpriv user domains user_t,
>> staff_t, etc.
> 
> Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.

Ok.  I don't see this as a good reason to allow this.  A user running a
daemon should be logging to their home directory.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Dominick Grift]

On Wed, Aug 24, 2011 at 10:16:24AM -0400, Christopher J. PeBenito wrote:
> On 08/24/11 09:51, Dominick Grift wrote:
> > On Wed, Aug 24, 2011 at 09:41:10AM -0400, Christopher J. PeBenito wrote:
> >> On 08/24/11 09:15, Dominick Grift wrote:
> >>> On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
> >>>> On 08/23/11 06:57, Sven Vermeulen wrote:
> >  ... snip ... 
> >>> I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
> >>
> >> Thats a different domain.  I'm speaking of unpriv user domains user_t,
> >> staff_t, etc.
> > 
> > Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
> 
> Ok.  I don't see this as a good reason to allow this.  A user running a
> daemon should be logging to their home directory.

Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.

It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.

So in light of that it may be sensible to allow administrators to tune the policy to allow Git session daemon to syslog. 

> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110824/780a8f2c/attachment.bin 

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Christopher J. PeBenito]

On 08/24/11 10:31, Dominick Grift wrote:
> On Wed, Aug 24, 2011 at 10:16:24AM -0400, Christopher J. PeBenito wrote:
>> On 08/24/11 09:51, Dominick Grift wrote:
>>> On Wed, Aug 24, 2011 at 09:41:10AM -0400, Christopher J. PeBenito wrote:
>>>> On 08/24/11 09:15, Dominick Grift wrote:
>>>>> On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
>>>>>> On 08/23/11 06:57, Sven Vermeulen wrote:
>>>  ... snip ... 
>>>>> I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
>>>>
>>>> Thats a different domain.  I'm speaking of unpriv user domains user_t,
>>>> staff_t, etc.
>>>
>>> Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
>>
>> Ok.  I don't see this as a good reason to allow this.  A user running a
>> daemon should be logging to their home directory.
> 
> Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.
> 
> It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.

If a user can run it as a user service w/o inetd, then why can't it run
as a system service w/o inetd?  Why cant you use start-stop-daemon or su
to run it with a different uid?

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Dominick Grift]

On Wed, Aug 24, 2011 at 12:11:11PM -0400, Christopher J. PeBenito wrote:
> On 08/24/11 10:31, Dominick Grift wrote:
> > On Wed, Aug 24, 2011 at 10:16:24AM -0400, Christopher J. PeBenito wrote:
> >> On 08/24/11 09:51, Dominick Grift wrote:
> >>> On Wed, Aug 24, 2011 at 09:41:10AM -0400, Christopher J. PeBenito wrote:
> >>>> On 08/24/11 09:15, Dominick Grift wrote:
> >>>>> On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
> >>>>>> On 08/23/11 06:57, Sven Vermeulen wrote:
> >>>  ... snip ... 
> >>>>> I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
> >>>>
> >>>> Thats a different domain.  I'm speaking of unpriv user domains user_t,
> >>>> staff_t, etc.
> >>>
> >>> Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
> >>
> >> Ok.  I don't see this as a good reason to allow this.  A user running a
> >> daemon should be logging to their home directory.
> > 
> > Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.
> > 
> > It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.
> 
> If a user can run it as a user service w/o inetd, then why can't it run
> as a system service w/o inetd? 

It could but that is not supported by default (there is no sysv init script) atleast not in Fedora.

> Why cant you use start-stop-daemon or su to run it with a different uid?

I guess yoo could, but what is your point? By default on (x)?inetd system service is supported. Sure you can hack around that and make it an init daemon but should we support that? If you hack it to run it as a sysv init daemon then i guess you could use su in the init script (that doesnt exist) and run git-daemon as a system service and as an unpriv user at the same time.

The point is that it is meant to run as an xinetd service domain.

Actually you could specify in /etc/xinetd.d/git that you want to run it as an different user but you will still needs xinetd running. Administrator just might to want to run inetd just for Git.

I rather support a something that makes sense (admin being allowed to tune policy to allow git user daemons to log to syslog in case desired), than support some hypothetical scenario where some admin decides to hack some sysv init script to get Git daemon to run as an init daemon instead of the supported xinetd service domain.

> 
> --
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110824/cb15e029/attachment.bin 

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Christopher J. PeBenito]

On 08/24/11 12:23, Dominick Grift wrote:
> On Wed, Aug 24, 2011 at 12:11:11PM -0400, Christopher J. PeBenito wrote:
>> On 08/24/11 10:31, Dominick Grift wrote:
>>> On Wed, Aug 24, 2011 at 10:16:24AM -0400, Christopher J. PeBenito wrote:
>>>> On 08/24/11 09:51, Dominick Grift wrote:
>>>>> On Wed, Aug 24, 2011 at 09:41:10AM -0400, Christopher J. PeBenito wrote:
>>>>>> On 08/24/11 09:15, Dominick Grift wrote:
>>>>>>> On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
>>>>>>>> On 08/23/11 06:57, Sven Vermeulen wrote:
>>>>>  ... snip ... 
>>>>>>> I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
>>>>>>
>>>>>> Thats a different domain.  I'm speaking of unpriv user domains user_t,
>>>>>> staff_t, etc.
>>>>>
>>>>> Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
>>>>
>>>> Ok.  I don't see this as a good reason to allow this.  A user running a
>>>> daemon should be logging to their home directory.
>>>
>>> Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.
>>>
>>> It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.
>>
>> If a user can run it as a user service w/o inetd, then why can't it run
>> as a system service w/o inetd? 
> 
> It could but that is not supported by default (there is no sysv init script) atleast not in Fedora.
> 
>> Why cant you use start-stop-daemon or su to run it with a different uid?
> 
> I guess yoo could, but what is your point? By default on (x)?inetd system service is supported. Sure you can hack around that and make it an init daemon but should we support that? If you hack it to run it as a sysv init daemon then i guess you could use su in the init script (that doesnt exist) and run git-daemon as a system service and as an unpriv user at the same time.
> 
> The point is that it is meant to run as an xinetd service domain.
> 
> Actually you could specify in /etc/xinetd.d/git that you want to run it as an different user but you will still needs xinetd running. Administrator just might to want to run inetd just for Git.
> 
> I rather support a something that makes sense (admin being allowed to tune policy to allow git user daemons to log to syslog in case desired), than support some hypothetical scenario where some admin decides to hack some sysv init script to get Git daemon to run as an init daemon instead of the supported xinetd service domain.

Frankly, I think that users running git daemons is just as contrived, if
not more.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Dominick Grift]

On Thu, Aug 25, 2011 at 07:09:30AM -0400, Christopher J. PeBenito wrote:
> On 08/24/11 12:23, Dominick Grift wrote:
> > On Wed, Aug 24, 2011 at 12:11:11PM -0400, Christopher J. PeBenito wrote:
> >> On 08/24/11 10:31, Dominick Grift wrote:
> >>> On Wed, Aug 24, 2011 at 10:16:24AM -0400, Christopher J. PeBenito wrote:
> >>>> On 08/24/11 09:51, Dominick Grift wrote:
> >>>>> On Wed, Aug 24, 2011 at 09:41:10AM -0400, Christopher J. PeBenito wrote:
> >>>>>> On 08/24/11 09:15, Dominick Grift wrote:
> >>>>>>> On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
> >>>>>>>> On 08/23/11 06:57, Sven Vermeulen wrote:
> >>>>>  ... snip ... 
> >>>>>>> I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
> >>>>>>
> >>>>>> Thats a different domain.  I'm speaking of unpriv user domains user_t,
> >>>>>> staff_t, etc.
> >>>>>
> >>>>> Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
> >>>>
> >>>> Ok.  I don't see this as a good reason to allow this.  A user running a
> >>>> daemon should be logging to their home directory.
> >>>
> >>> Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.
> >>>
> >>> It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.
> >>
> >> If a user can run it as a user service w/o inetd, then why can't it run
> >> as a system service w/o inetd? 
> > 
> > It could but that is not supported by default (there is no sysv init script) atleast not in Fedora.
> > 
> >> Why cant you use start-stop-daemon or su to run it with a different uid?
> > 
> > I guess yoo could, but what is your point? By default on (x)?inetd system service is supported. Sure you can hack around that and make it an init daemon but should we support that? If you hack it to run it as a sysv init daemon then i guess you could use su in the init script (that doesnt exist) and run git-daemon as a system service and as an unpriv user at the same time.
> > 
> > The point is that it is meant to run as an xinetd service domain.
> > 
> > Actually you could specify in /etc/xinetd.d/git that you want to run it as an different user but you will still needs xinetd running. Administrator just might to want to run inetd just for Git.
> > 
> > I rather support a something that makes sense (admin being allowed to tune policy to allow git user daemons to log to syslog in case desired), than support some hypothetical scenario where some admin decides to hack some sysv init script to get Git daemon to run as an init daemon instead of the supported xinetd service domain.
> 
> Frankly, I think that users running git daemons is just as contrived, if
> not more.

I suspected that this convo was moving this way.

Is it our job to tell people what they can and cannot do? I do not believe so.
I believe it is our job to facilitate integrity in the case of Type Enforcement; not to cripple the system by ignoring functionality.

That said, i do agree with your point in general, i just think we should leave that decision to the administrator and support both assumptions.

In the case of Git sessions using syslog, i would say make it tunable and disable by default.

If you do not want unprivileged users to run git sessions at all, i can imagine that to. So we could remove the session role templates calls but still leave the template in the interface file, so that i could be called if desired.

Or we could make unprivileged user domain transitions to the git session domain tunable as well.

But ignoring functionality altogether does not make SELinux a credible access control layer that can be supported by default (think Redhat, the distro that has the gut and sense of leadership to enable SELinux by default) in my opinion.

> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110825/4e226e75/attachment.bin 

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Dominick Grift]

On Wed, Aug 24, 2011 at 12:11:11PM -0400, Christopher J. PeBenito wrote:
> On 08/24/11 10:31, Dominick Grift wrote:
> > On Wed, Aug 24, 2011 at 10:16:24AM -0400, Christopher J. PeBenito wrote:
> >> On 08/24/11 09:51, Dominick Grift wrote:
> >>> On Wed, Aug 24, 2011 at 09:41:10AM -0400, Christopher J. PeBenito wrote:
> >>>> On 08/24/11 09:15, Dominick Grift wrote:
> >>>>> On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
> >>>>>> On 08/23/11 06:57, Sven Vermeulen wrote:
> >>>  ... snip ... 
> >>>>> I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
> >>>>
> >>>> Thats a different domain.  I'm speaking of unpriv user domains user_t,
> >>>> staff_t, etc.
> >>>
> >>> Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
> >>
> >> Ok.  I don't see this as a good reason to allow this.  A user running a
> >> daemon should be logging to their home directory.
> > 
> > Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.
> > 
> > It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.
> 
> If a user can run it as a user service w/o inetd, then why can't it run
> as a system service w/o inetd?  Why cant you use start-stop-daemon or su
> to run it with a different uid?

Anyhow, if the git session daemon policy is generally accepted. i will be more than happy to send an additional patch removing the privilege for git_session_t to use syslog.  Better something than nothing at all...

> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110825/97c73acd/attachment.bin 

[refpolicy] [PATCH 1/1] Allow userdomains to send syslog messages

[Sven Vermeulen]

On Wed, Aug 24, 2011 at 09:10:00AM -0400, Christopher J. PeBenito wrote:
> On 08/23/11 06:57, Sven Vermeulen wrote:
> > Some applications that run within the user domain send messages to the syslog
> > daemon (for instance through the syslog() function). This patch allows the
> > userdomain to write to the devlog_t socket and interact properly with the
> > syslog daemon.
> 
> Do you have some examples?  My initial reaction is definitely not
> merged, as I don't want users to be able to flood the system logs.
> 

The one that triggered the creation of the patch was to support bashlogger
(feature of bash that logs all activity to the system logger). Another one
we had a way back (but I just informed the user how to allow it for himself
then) was for a chat client (i think it was weechatter, but the case was
applicable to others as well) configured to log things to the system log.

I don't mind if this is deemed a bit too intrusive for regular purposes.

Wkr,
	Sven Vermeulen