From mboxrd@z Thu Jan  1 00:00:00 1970
From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Thu, 25 Aug 2011 07:09:30 -0400
Subject: [refpolicy] [PATCH 1/1] Allow userdomains to send syslog
	messages
In-Reply-To: <20110824162349.GD25303@localhost.localdomain>
References: <20110823105722.GA2352@siphos.be> <4E54F828.8020200@tresys.com>
	<20110824131507.GA25303@localhost.localdomain>
	<4E54FF76.2040804@tresys.com>
	<20110824135105.GB25303@localhost.localdomain>
	<4E5507B8.3080609@tresys.com>
	<20110824143108.GC25303@localhost.localdomain>
	<4E55229F.4000700@tresys.com>
	<20110824162349.GD25303@localhost.localdomain>
Message-ID: <4E562D6A.2090105@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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