| Summary: | Permission denied to CVSROOT after update | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Domingo Becker <domingobecker> |
| Component: | cvs | Assignee: | Petr Pisar <ppisar> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 13 | CC: | ppisar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-02-14 21:21:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Which version of cvs package did you have before the update acceptance (/var/log/yum.log)? Latest update of cvs in F13 (1.11.23-11) has just changed profile file for (t)csh (/etc/profile.d/cvs.csh). It should not affect anything except clients using that shell. (It fixed the SSH transport for remote shell call by setting CVS_RSH variable properly.) Whether you have problems with SELinux, you can check in /var/log/audit/audit.log. Does appear new message in the log if you try to do the check-out? It can happen you updated SELinux policy that broke your cvs server. Policies are delivered by different package (selinux-policy). The error message is printed when CVS server verifies accessibility of CVSROOT. Do all intermediate directories of the `/d/cvs/CVSROOT' path have proper mode and SELinux labels? (In reply to comment #1) > Which version of cvs package did you have before the update acceptance > (/var/log/yum.log)? > # grep cvs- yum.log* Oct 29 08:53:07 Updated: cvs-1.11.23-10.fc13.i686 Feb 01 21:32:11 Updated: cvs-1.11.23-11.fc13.i686 > Latest update of cvs in F13 (1.11.23-11) has just changed profile file for > (t)csh (/etc/profile.d/cvs.csh). It should not affect anything except clients > using that shell. (It fixed the SSH transport for remote shell call by setting > CVS_RSH variable properly.) > I'm using pserver, not ssh. > Whether you have problems with SELinux, you can check in > /var/log/audit/audit.log. Does appear new message in the log if you try to do > the check-out? > Nope. Nothing new appears when I try to update a module. But let's try to make it work under SELinux in permissive mode. In winblow, with CVSNT I get "permission denied on /d/cvs/CVSROOT/cvsignore" and that file does not exist in /d/cvs/CVSROOT/. In Fedora, I get "permission denied on /d/cvs/CVSROOT". > It can happen you updated SELinux policy that broke your cvs server. Policies > are delivered by different package (selinux-policy). > We can exclude SELinux in this discussion because if I put it in permissive mode I get the same error. If I can get it to work with SELinux in permissive mode, I can take care of adding the necessary policy modules to allow cvs to works just fine. I added new 3 policy modules to allow cvs to access /d/cvs and some new file label information for that directory too (for restorecon). > The error message is printed when CVS server verifies accessibility of CVSROOT. > Do all intermediate directories of the `/d/cvs/CVSROOT' path have proper mode > and SELinux labels? I included ls -lh to see the DAC permissions and ls -Z to see the SELinux info from /d/cvs and /d/cvs/CVSROOT in the first message. Thank you. > # grep cvs- yum.log* > Oct 29 08:53:07 Updated: cvs-1.11.23-10.fc13.i686 > Feb 01 21:32:11 Updated: cvs-1.11.23-11.fc13.i686 And what will happen, if you downgrade the cvs to 1.11.23-10? I did not touch sources in between the two revisions, so I really suspect some change in your file system. > Nope. Nothing new appears when I try to update a module. Great, so it does not look like a denial caused by SELinux. Bugs in file system, cvs, glibc, and Linux remain. > I included ls -lh to see the DAC permissions and ls -Z to see the SELinux info > from /d/cvs and /d/cvs/CVSROOT in the first message. You should check all directories in the path: /, /d, /d/cvs, /d/cvs/CVSROOT because all of them are checked when accessing /d/cvs/CVSROOT. Files under /d/cvs/CVSROOT are not relevant. By the way the /d/cvs/CVSROOT directory is missing executable bit thus cvs server (if not running as root) should not be able to traverse the directory and should get ENOPERM as you got. (In reply to comment #3) > > By the way the /d/cvs/CVSROOT directory is missing executable bit thus cvs > server (if not running as root) should not be able to traverse the directory > and should get ENOPERM as you got. Oh, my lord! Now that you mention that bit, I remember what I did: I made a chmod 666 on /d/cvs. Why does it need the executable bit on? I made chmod 777 on /d/cvs and subdirs, and it's working again. Many thanks. (In reply to comment #4) > Why does it need the executable bit on? > http://en.wikipedia.org/wiki/Filesystem_permissions#Permissions |
Description of problem: I accepted an update for cvs package last Feb 01, 2011, and now I get the following error whe trying to "cvs co": Cannot access /d/cvs/CVSROOT Permission denied I have SELinux enabled with the appropriate policy modules created to allow cvs access to that directory. When I set SELinux in permissive mode, I still get the same error. My /etc/xinetd.d/cvs file has: service cvspserver { disable = no port = 2401 socket_type = stream protocol = tcp wait = no user = root passenv = PATH server = /usr/bin/cvs env = HOME=/d/cvs server_args = -f --allow-root=/d/cvs pserver # bind = 127.0.0.1 } The repository is in the same computer and a passwd file is created at /d/cvs/CVSROOT to allow access using user names. It looks like cvs binary is failing to access /d/cvs/CVSROOT as root. The output for some commands: ls -Z /d/cvs ... (cvs modules here) drw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 CVSROOT ... (some more cvs modules here) su -c 'ls -Z /d/cvs/CVSROOT' -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 checkoutlist -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 checkoutlist,v -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 commitinfo -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 commitinfo,v -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 config -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 config,v -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 cvswrappers -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 cvswrappers,v -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 editinfo -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 editinfo,v drw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 Emptydir -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 history -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 loginfo -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 loginfo,v -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 modules -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 modules,v -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 notify -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 notify,v -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 passwd -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 rcsinfo -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 rcsinfo,v -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 taginfo -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 taginfo,v -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 val-tags -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 verifymsg -rw-rw-rw-. root root system_u:object_r:cvs_data_t:s0 verifymsg,v ls -lh CVSROOT/ total 3,5M -rw-rw-rw-. 1 root root 495 dic 20 2007 checkoutlist -rw-rw-rw-. 1 root root 696 dic 20 2007 checkoutlist,v -rw-rw-rw-. 1 root root 760 dic 20 2007 commitinfo -rw-rw-rw-. 1 root root 961 dic 20 2007 commitinfo,v -rw-rw-rw-. 1 root root 991 jul 6 2009 config -rw-rw-rw-. 1 root root 1,2K dic 20 2007 config,v -rw-rw-rw-. 1 root root 602 dic 20 2007 cvswrappers -rw-rw-rw-. 1 root root 803 dic 20 2007 cvswrappers,v -rw-rw-rw-. 1 root root 1,1K dic 20 2007 editinfo -rw-rw-rw-. 1 root root 1,2K dic 20 2007 editinfo,v drw-rw-rw-. 2 root root 4,0K jul 20 2009 Emptydir -rw-rw-rw-. 1 root root 3,4M feb 3 21:24 history -rw-rw-rw-. 1 root root 1,2K dic 20 2007 loginfo -rw-rw-rw-. 1 root root 1,4K dic 20 2007 loginfo,v -rw-rw-rw-. 1 root root 1,2K dic 20 2007 modules -rw-rw-rw-. 1 root root 1,4K dic 20 2007 modules,v -rw-rw-rw-. 1 root root 564 dic 20 2007 notify -rw-rw-rw-. 1 root root 765 dic 20 2007 notify,v -rw-rw-rw-. 1 root root 42 jul 6 2009 passwd -rw-rw-rw-. 1 root root 649 dic 20 2007 rcsinfo -rw-rw-rw-. 1 root root 850 dic 20 2007 rcsinfo,v -rw-rw-rw-. 1 root root 879 dic 20 2007 taginfo -rw-rw-rw-. 1 root root 1,1K dic 20 2007 taginfo,v -rw-rw-rw-. 1 root root 0 dic 20 2007 val-tags -rw-rw-rw-. 1 root root 1,1K dic 20 2007 verifymsg -rw-rw-rw-. 1 root root 1,2K dic 20 2007 verifymsg,v It looks like the files were created with the appropriate usernames, access mode and selinux permissions. Any hint on how to solve this issue is very appreciated (it is my development repository and I need the version control system). I used this repository successfully under Fedora since 2007, and Fedora was upgraded successfully since Fedora Core 7 through Fedora 13 successfully using preupgrade or installation dvd, without problems with cvs access to my development repository. kind regards