summaryrefslogtreecommitdiff
path: root/contrib/hooks/update-paranoid
AgeCommit message (Collapse)AuthorFilesLines
2008-05-25Ignore no-op changes in paranoid update hookLibravatar Shawn O. Pearce1-0/+1
If the hook gets invoked with identical old and new ids there is no change taking place. We probably should not have been called, but instead of failing silently allow the no-op. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25Don't load missing ACL files in paranoid update hookLibravatar Shawn O. Pearce1-0/+1
If a user or group ACL file does not exist in the current tip revision of the acl repository we will get an error from cat-file when we ask for that blob as it cannot be resolved. A quick look at the history by rev-list can tell us if there is a path there or not. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25Don't diff empty tree on branch creation in paranoid update hookLibravatar Shawn O. Pearce1-8/+6
Listing all files in a branch during branch creation is silly; the user's file-level ACLs probably don't mean anything at this point. We now treat the base case of 0{40} as an empty diff, as this happens only when the user is creating the branch and there are file level ACLs that diff against the old value of the branch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-10Use the empty tree for base diff in paranoid-update on new branchesLibravatar Shawn O. Pearce1-10/+21
We have to load a tree difference for the purpose of testing file patterns. But if our branch is being created and there is no specific base to difference against in the rule our base will be '0'x40. This is (usually) not a valid tree-ish object in a Git repository, so there's nothing to difference against. Instead of creating the empty tree and running git-diff against that we just take the output of `ls-tree -r --name-only` and mark every returned pathname as an add. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-10Teach the update-paranoid to look at file differencesLibravatar Shawn O. Pearce1-7/+105
In some applications of the update hook a user may be allowed to modify a branch, but only if the file level difference is also an allowed change. This is the commonly requested feature of allowing users to modify only certain files. A new repository.*.allow syntax permits granting the three basic file level operations: A: file is added relative to the other tree M: file exists in both trees, but its SHA-1 or mode differs D: file is removed relative to the other tree on a per-branch and path-name basis. The user must also have a branch level allow line already granting them access to create, rewind or update (CRU) that branch before the hook will consult any file level rules. In order for a branch change to succeed _all_ files that differ relative to some base (by default the old value of this branch, but it can also be any valid tree-ish) must be allowed by file level allow rules. A push is rejected if any diff exists that is not covered by at least one allow rule. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-10Teach update-paranoid how to store ACLs organized by groupsLibravatar Shawn O. Pearce1-16/+44
In some applications of this paranoid update hook the set of ACL rules that need to be applied to a user can be large, and the number of users that those rules must also be applied to can be more than a handful of individuals. Rather than repeating the same rules multiple times (once for each user) we now allow users to be members of groups, where the group supplies the list of ACL rules. For various reasons we don't depend on the underlying OS groups and instead perform our own group handling. Users can be made a member of one or more groups by setting the user.memberOf property within the "users/$who.acl" file: [user] memberOf = developer memberOf = administrator This will cause the hook to also parse the "groups/$groupname.acl" file for each value of user.memberOf, and merge any allow rules that match the current repository with the user's own private rules (if they had any). Since some rules are basically the same but may have a component differ based on the individual user, any user.* key may be inserted into a rule using the "${user.foo}" syntax. The allow rule does not match if the user does not define one (and exactly one) value for the key "foo". Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-19Contribute a fairly paranoid update hookLibravatar Shawn O. Pearce1-0/+284
I'm using a variant of this update hook in a corporate environment where we perform some validations of the commits and tags that are being pushed. The model is a "central repository" type setup, where users are given access to push to specific branches within the shared central repository. In this particular installation we run a specially patched git-receive-pack in setuid mode via SSH, allowing all writes into the repository as the repository owner, but only if this hook blesses it. One of the major checks we perform with this hook is that the 'committer' line of a commit, or the 'tagger' line of a new annotated tag actually correlates to the UNIX user who is performing the push. Users can falsify these lines on their local repositories, but the central repository that management trusts will reject all such forgery attempts. Of course 'author' lines are still allowed to be any value, as sometimes changes do come from other individuals. Another nice feature of this hook is the access control lists for all repositories on the system can also be stored and tracked in a supporting Git repository, which can also be access controlled by itself. This allows full auditing of who-had-what-when-and-why, thanks to git-blame's data mining capabilities. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>