[refpolicy] [ v3 PATCH 4/8] Git session daemon

[domg472@gmail.com (Dominick Grift)]

On Tue, Aug 30, 2011 at 09:50:48AM -0400, Christopher J. PeBenito wrote:
> 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.

Really? apache module has httpd_user_content_t with out a user session (yes you can run httpd_t as a session daemon)
Anyways, duly noted. I can do what you want.

> 
> >> 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.

I think i did right. I think that if i have the git daemon domain type git_system_t in my first patch my might have complained about that name. I anticipated that and called it gitd_t instead for that reason only.

Anyways, sure i can do what you want and call it git_system_t from the get go.

> >> 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
-------------- 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/20110830/83289e3d/attachment.bin