From: domg472@gmail.com (Dominick Grift) Date: Tue, 30 Aug 2011 19:20:17 +0200 Subject: [refpolicy] [ v3 PATCH 4/8] Git session daemon In-Reply-To: <4E5CEAB8.2010802@tresys.com> 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> <4E5CEAB8.2010802@tresys.com> Message-ID: <20110830172016.GC6861@localhost.localdomain> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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