Setting up CVS repository and avoiding Selinux issues?

[Daniel B. Thurman]

Daniel J Walsh wrote:
> On 04/29/2009 11:20 AM, Daniel B. Thurman wrote:
>> Daniel J Walsh wrote:
>>> On 04/28/2009 10:07 PM, Daniel B. Thurman wrote:
>>>>
>>>>
>>>> I am trying to get my CVS repository setup. Apparently,
>>>> it appears that the repository must be in the root directory,
>>>> otherwise I get selinux permission denials.
>>>>
>>>> What I tried to do initially was to locate the repository
>>>> on a NTFS filesystem for which the context is fusefs
>>>> which could not be changed, no matter what I tried.
>>>> I got selinux permission errors.
>>>>
>>>> Giving that up, I moved the repository to a ext3 filesystem
>>>> located on a separate drive/partition, mounted on /f-App1,
>>>> where the repository is located @ /f-App1/Develop/cvs, and did:
>>>>
>>>> cd /f-App1/Develop/
>>>> chown -R cvs:cvs cvs
>>>> chcon -R -t cvs_data_t cvs
>>>> find cvs -type d -exec chmod 755 {} \;
>>>> find cvs -type t -exec chmod 754 {} \;
>>>> ln -s /f-App1/Develop/cvs /cvs
>>>>
>>>> and I got selinux complaining that the files are not /cvs rooted.
>>>>
>>>> So I did:
>>>>
>>>> cp -a /f-App1/Develop/cvs /cvs1
>>>> rm -f /cvs
>>>> ln -s /cvs1 /cvs
>>>>
>>>> And it worked.
>>>>
>>>> How can I place my repository in a non-rooted, non-standard
>>>> repository location and avoid the selinux complaints?
>>>
>>> I blogged on your email
>>>
>>> http://danwalsh.livejournal.com/28027.html
>>>
>> Thanks a lot Dan! I will see what I can do to resolve
>> my CVS issues. Please read my posting in reply to Todd
>> Dennison. I was asking myself why the "all or nothing
>> proposition", and about using selinux context with more
>> flexibility than what we have? I understand that security
>> prevails over flexibility but I was wondering if there was
>> a way to gain more flexibility and yet still retain security?
>>
> Well I would argue they are very flexible.  I did give you a couple of 
> solutions but there are theoretically multiple others.
>
> And I am always willing to accept other solutions.
>
> svn and git seem to be using http_sys_content_t for their context so I 
> guess we could attempt to allow those domains access to cvs_data?
>> For example, if multiple context / file was possible, then
>> one could theoretically traverse from the top of the tree
>> to allow passage to the leaf of the tree? Yes I can imagine
>> it is a bit more complexity, but... if security is not compromised,
>> then, perhaps it's worth it?
>>
> I guess maybe we should have had this conversation on the blog.  There 
> are many context that most confined services can traverse.  For 
> example usr_t, etc_t, var_t
>
> I have added a comment to my blog.
>> PS: For some reason or another, I am no longer receiving
>> Fedora SeLinux mailing list postings. Is the Fedora SeLinux
>> mailing list still active?
>>
> Yes.  This list is still available.
>
> Last message is 4/28 fron me.  :^)
>
>> Kind regards,
>> Dan
>>
>
[Also posted to LiveJournal, but placed here for those
 who do not have access to or cannot read LJ. ]

Hi Dan,

I have read your blog and it is quite informative.  What I ended
up doing is is to:

1) chcon -t cvs_data_t /f-App1
2) chcon -t cvs_data_t /f-App1/Develop
3) chcon -t cvs_data_t /f-App1/Develop/SC
4) chcon -t cvs_data_t /f-App1/Develop/SC/cvs

If one uses cvs command: cvs login, it works,
and no errors and selinux complaints.  However...

If one uses an Eclipse or Netbeans IDE, logging
into cvs via their interfaces reports an error
that the User's home directory is not of proper
context: cvs_data_t.  So adding in one more step:

5) chcon -t cvs_data_t $HOME/dant

Solves the problem.

Please note that once the Repository "tree" is resolved,
adding a 6th step:

6) ln -s /f-App1/Develop/SC/cvs /cvs

And changing the cvs configuration such that
the pathname is chamged to: /cvs (instead of
using the actual pathname of the repository)
and restarting xinet and resetting the CVSROOT
variable, now all works fine.  No CVS nor Selinux
errors, so far.

How about selinux context, what I was proposing
was to add the capability to have multiple context.
For example, starting with /f-App1 directory, if
I wanted to allow cvs and svn access, I would add
this context as follows:

chcon -default -t default_t   /f-App1
chcon -add     -t cvs_data_t  /f-App1
chcon -add     -t svn_data_t  /f-App1

So, you should be able to add/append/delete/remove/...
commands to manipulate selinux context, unless there
is something about how context on the physical drive
that does not make this possible?