Attached is my latest take on confining Git daemon. I removed Git user domain and userdom_git_user_template and added a git_daemon_git_user_template instead. There is no user domain able to read or write git_daemon_system_content. One would have to create a user domain, call git_daemon_git_user_template in it, and since the Git user domain has to be a primary domain, one would also have a default user context. Also note that apache calls git_daemon_read_all_git_content in an optional policy block. I have tried to wrap this call into a tunable block first and then into optional policy. Although this did compile, it did not yield the expected results. This is why i decided to not make this tunable. It has to optional in my view. The Git daemon domain is a coarse implementation. Content only has two general types, system content and user content. Because Git daemon uses SSH daemon to push content, the system ACLs are transparent. This means i may be able to implement finer grained access control. For example which Git user domain may access which Git daemon content? Attachement: http://pastebin.ca/1093095 -- Dominick Grift <domg472@xxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part
