Daniel B. Thurman wrote:
(snip)
Bind mount:
========
Ok, the issue is solved. What I did not know is, you need to make sure
that when
you create an empty directory, you also need to make sure that the
ownership
of that directory is: cvs:cvs before bind mounting. So:
1) mkdir /cvs
2) chown cvs:cvs /cvs
then
3) mount --bind /var/cvs /cvs
it all works now!
mount --bind /var/cvs /cvs
ls -ldZ /cvs:
=======
drwxr-xr-x cvs cvs system_u:object_r:cvs_t:s0 /cvs
So, the context is right, but still get a Permissions denied.
/sbin/ausearch -i -m AVC
================
type=SYSCALL msg=audit(02/14/2008 11:08:09.984:7732) : arch=i386
syscall=fchmodat success=no exit=-13(Permission denied)
a0=ffffff9c a1=94848d8 a2=1fd a3=94848d8 items=0 ppid=23862
pid=20445 auid=dant uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=pts7 comm=chmod
exe=/bin/chmod subj=system_u:system_r:unconfined_t:s0 key=(null)
type=AVC msg=audit(02/14/2008 11:08:09.984:7732) : avc: denied
{ setattr } for pid=20445 comm=chmod name=cvs dev=sdb5 ino=819450
scontext=system_u:system_r:unconfined_t:s0
tcontext=system_u:object_r:cvs_t:s0 tclass=dir
Oh rats! This error above was for something else! My mistake!!!!
I had to trying logging in at the remote system but failed several
times,
but after the 3rd try, I finally got in. Not sure why the login
process
stumbled.
So, It DOES work!
But I am having a problem with getting Eclipse's SVN to open a single
file:
The server reported an error while performing the "cvs status"
command.
HelloWorld: cvs status: failed to create lock directory for
`/cvs/Eclipse/C/Examples/HelloWorld' (/cvs/Eclipse/C/Examples/HelloWorld/#cvs.lock): Permission denied
HelloWorld: cvs status: failed to obtain dir lock in repository
`/cvs/Eclipse/C/Examples/HelloWorld'
HelloWorld: cvs [status aborted]: read lock failed - giving up
Not sure why it is not able to lock this file for
checkout/examination. Any ideas?
See note above...
To Stephen: "/sbin/ausearch -i -m AVC"
type=SYSCALL msg=audit(02/13/2008 19:17:32.484:5097) : arch=i386
syscall=open success=no exit=-13(Permission denied) a0=8faf660
a1=8000 a2=1b6 a3=8fafa58 items=0 ppid=25427 pid=27015 auid=dant
uid=root gid=root euid=root suid=root fsuid=root egid=root
sgid=root fsgid=root tty=(none) comm=cvs exe=/usr/bin/cvs
subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(02/13/2008 19:17:32.484:5097) : avc: denied
{ read } for pid=27015 comm=cvs name=cvs dev=sdb5 ino=49172
scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023
tcontext=system_u:object_r:default_t:s0 tclass=lnk_file
Thanks for responding!
Dan
But of course, what about the symlink method?
Is this now a moot issue and can be ignored?
The policy rules for symlinks are distinct from those for regular files,
directories etc. So when the usual, expected filesystem layout for an
application and its data doesn't use a symlink, there's unlikely to be
selinux policy for following syminks for that application.
The admin's old trick of shuffling data around and putting a symlink to
the new location from the old location probably needs to be accompanied
in most cases by local policy modifications to establish the contexts
for files in the new locations, and to allow the symlink to be followed.
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
