From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 30 Aug 2011 09:50:48 -0400
Subject: [refpolicy] [ v3 PATCH 4/8] Git session daemon
In-Reply-To: <20110826153009.GA8869@localhost.localdomain>
References: <1314189346-10866-1-git-send-email-domg472@gmail.com>
	<1314189346-10866-5-git-send-email-domg472@gmail.com>
	<4E57A0C2.7010407@tresys.com>
	<20110826153009.GA8869@localhost.localdomain>
Message-ID: <4E5CEAB8.2010802@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 08/26/11 11:30, Dominick Grift wrote:
> On Fri, Aug 26, 2011 at 09:33:54AM -0400, Christopher J. PeBenito wrote:
>> On 08/24/11 08:35, Dominick Grift wrote:
>>> Wait! Theres more. Besides running Git daemon as a inetd service domain, unprivileged users can also
>>> run Git daemon by executing /usr/libexec/git-core/git-daemon from a shell to allow it to
>>> read and serve their Git personal repositories in ~/public_git. It in large parts does the same
>>> as Git daemon run by inetd but there are some differences. Most notably is the network access
>>> that the Git session daemon requires to listen on the Git port for service.
>>>
>>> The Git system daemon does not need this because inetd takes care of the network for it.
>>> Another difference is that Git session daemon can only read and serve users Git personal
>>> repositories, where Git system daemon can, if configured, read and serve both shared as well
>>> as personal repositories. Since much of the policy is common to both session and
>>> system, we declared a git_daemon attribute and assigned that to both the Git system and
>>> session daemons. This allows use to write policy that both daemon have in common once.
>>> Leaving the policy as compact as possible. So now we have two Git daemon domains, one
>>> session domain started by unprivileged users and one system domain started by inetd.
>>>
>>> Fix: since we renamed gitd_t to git_system_t, add alias.
>>> Change back gitd_use_nfs, gitd_use_cifs to git_system_use_nfs and git_system_use_cifs respectively
>>
>> Perhaps I missed something, but how did it make sense to separate out
>> the content types from this patch?
> 
> The git_user_content_t has no relation to git session per se. 
> 
> in the git.fc file there is a context spec for HOME_DIR/\public_git(/.*)? ...
> this means all login users will get content at ~/public_git labeled git_user_content_t, whether they call git_session_role_template or not.
> So they need to be able to manage that. what if a user creates ~/pubic_git, and administrator runs filefiles relabel or restorecon -R -v /home? then ~/public_git will get relabeled to git_user_content_t and that user can no longer interact with it.
> 
> By splitting the git_user_content_t type from the git session t policy we make it more flexible.
> 
> administrator may want to allow git system domain to read and service ~/public_git even though the user owning it is not allowed to run git session in the git session domain.
> 
> in short git_user_content_t and git_session_t arent strictly related. I was hoping the descriptions accompanying the patches would make that clear

NAK.  See my other email about this.  To summarize, I think its overengineered
to have the content w/o session.

>> I'm confused why its renaming things from previous patches.  Why not
>> create it right in the first place?
> 
> I initially started with gitd_t rather than git_system_t because that made sense at that stage. There was no git_session_t yet at that point. Besides, what does it matter i created an alias to git_system_t in the patch that introduce git session t

So, in other words, these patches reflect how your development flow went.  In
the future please try to clean up submissions, as these type of changes make it
confusing for review.

>> git_session_role_template() isn't creating any types, so it should be
>> renamed to git_session_role().  Or in light of the previous patches,
>> git_role().
> 
> Ok that pretty minor and i can just submit a patch to apply that after the other applicable patches are submitted.

Thats fine.

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