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?
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
