On Mon, Jun 7, 2021 at 10:47 PM Anthony LaTorre <tlatorre9@xxxxxxxxx> wrote: > I eventually found out that I needed to run: > > # restorecon -vR /var/lib/git/ > > which fixed the issue, but I thought it was supposed to happen > automatically since there was already a rule which was supposed to > set these as type git_content_t (I think that's it). > > I emailed the cgit package maintainer and he was suprised too, and > has since updated the README to include instructions to run > restorecon, but I was curious as to whether this should be > necessary. Why doesn't the /var/lib/git directory get the correct > context? Performance. Calculating the correct SELinux file context for an arbitrary path in the filesystem can be nontrivial (e.g., requiring parsing regular expressions). If the kernel did this by default for every object created in the filesystem, performance would be terrible. Since the vast majority of the time the correct context for a new file/directory is the same as the parent directory, in order to prevent SELinux from tanking performance, new files/directories inherit the file context of the parent directory unless either 1) the application is SELinux-aware and requests a specific context, or 2) there is a type transition that specifies a specific context. Modern versions of mkdir are SELinux-aware and support the -Z option to atomically create a directory with the correct SELinux file context: $ mkdir -Z /var/lib/git But running restorecon after the fact also works. _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure