Description of problem: We have a /project space on fedorapeople.org that serves out via http and has a mixture of plain files/dirs and git repos. We'd like to serve the git repos via git-daemon from xinetd. The issue is that for apache to access the symlinks the files must be httpd_sys_content_t but for git-daemon to access the files the files must be git_system_content_t. With the files in the git_system_content_t apache works pretty well, except for symlinks. After discussion with some folks at kernel.org where they are doing similar things the issue seems to be a minor change to the git policy to allow access for symlinks. read_lnk_files_pattern(.....etc) Version-Release number of selected component (if applicable): selinux-policy-targeted-3.7.19-155.el6_3.4.noarch How reproducible: set up a git repo and a dir export the dir using git-daemon from xinetd and export the dir via apache. set the file contexts to git_system_content_d and then create a symlink - try to access that symlink via apache (set FollowSymLinks in apache) any help is welcome.
Yes, I see we have sesearch -A -s httpd_t -t git_system_content_t Found 3 semantic av rules: allow httpd_t git_sys_content_t : file { ioctl read getattr lock open } ; allow httpd_t git_sys_content_t : dir { ioctl read getattr lock search open } We need to add read_lnk_files_pattern($1, git_system_content_t, git_system_content_t) to git_read_generic_system_content_files() interface.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0314.html