primary Fedora and some negligibilities...hauptsächlich Fedora und ein paar Nebensächlichkeiten...
With regard to cgit and SELinux in Fedora (13)There should be no need to do anything:1. By default "/var/www/cgi-bin/cgit" is labelled type "httpd_git_script_exec_t"2. By default "/var/cache/cgit" is labelled type "httpd_git_rw_content_t"3. By default "/etc/cgitrc" is labelled type "etc_t"When booleans:httpd_enable_cgi -> on Allow httpd cgi supporthttpd_builtin_scripting -> on Allow httpd to use built in scripting (usually php)Are toggled to on (should be on by default i believe), then the "httpd_t" domain (apache) will domain transition to the "httpd_git_script_t" domain when it runs "/var/www/cgi-bin/cgit"The "httpd_git_script_t" domain has permission to read "all" Git system content (shared repositories in "/var/lib/git"So in theory, things should just work. Please test this and provide feedback so that if it does not work, that we can fix it.Side note: The git-daemon is now also confined by SELinux in Fedora. This policy allows, amongst other things, that you can seperate various git-shell SELinux users.That means you can use SELinux to govern what user (groups) can access the different shared repositories.This is, in my view, a nice feature for mass hosters of git repositories. Because it does not rely on DAC for access to the various content.Feedback with regard to git-daemon is also very much appreciated.
There is a small error in my previous reply:httpd_git_script_t domain has read access to *all" repositories, so not just shared repositories but also personal repositories in the user home (public_git by default)So instead of labelling /path/to/repository type httpd_sys_content_t, one should use type git_system_content_t or git_session_content_t depending on the nature of the repository.If you use any other type like httpd_sys_content_t, then the git_daemon can no longer read it, and git_shell (git_shell_u) users can no longer manage git system content.