Скотт Чакон - Pro Git

avail|nickh,pjhyett,defunkt,tpw

avail|usinclair,cdickens,ebronte|doc

avail|schacon|lib

avail|schacon|tests

You begin by reading this data into a structure that you can use. In this case, to keep the example simple, you’ll only enforce the avail directives. Here is a method that gives you an associative array where the key is the user name and the value is an array of paths to which the user has write access:

defget_acl_access_data(acl_file)

# read in ACL data

acl_file = File.read(acl_file).split( " \n" ).reject { |line| line == '' }

access = {}

acl_file.each do|line|

avail, users, path = line.split( '|' )

next unlessavail == 'avail'

users.split( ',' ).each do|user|

access[user] ||= []

access[user] << path

end

end

access

end

On the ACL file you looked at earlier, this get_acl_access_data method returns a data structure that looks like this:

{ "defunkt" =>[ nil],

"tpw" =>[ nil],

"nickh" =>[ nil],

"pjhyett" =>[ nil],

"schacon" =>[ "lib" , "tests" ],

"cdickens" =>[ "doc" ],

"usinclair" =>[ "doc" ],

"ebronte" =>[ "doc" ]}

Now that you have the permissions sorted out, you need to determine what paths the commits being pushed have modified, so you can make sure the user who’s pushing has access to all of them.

You can pretty easily see what files have been modified in a single commit with the --name-only option to the git log command (mentioned briefly in Chapter 2):

$git log -1 --name-only --pretty=format: '' 9f585d

README

lib/test.rb

If you use the ACL structure returned from the get_acl_access_data method and check it against the listed files in each of the commits, you can determine whether the user has access to push all of their commits:

# only allows certain users to modify certain subdirectories in a project

defcheck_directory_perms

access = get_acl_access_data( 'acl' )

# see if anyone is trying to push something they can't

new_commits = `git rev-list #{ $oldrev }.. #{ $newrev }` .split( " \n" )

new_commits.each do|rev|

files_modified = `git log -1 --name-only --pretty=format:'' #{ rev }` .split( " \n" )

files_modified.each do|path|

next ifpath.size == 0

has_file_access = false

access[$user].each do|access_path|

if!access_path # user has access to everything

|| (path.start_with? access_path) # access to this path

has_file_access = true

end

end

if!has_file_access

puts "[POLICY] You do not have access to push to #{ path }"

exit 1

end

end

end

end

check_directory_perms

You get a list of new commits being pushed to your server with git rev-list. Then, for each of those commits, you find which files are modified and make sure the user who’s pushing has access to all the paths being modified.

Now your users can’t push any commits with badly formed messages or with modified files outside of their designated paths.

If you run chmod u+x .git/hooks/update, which is the file into which you should have put all this code, and then try to push a commit with a non-compliant message, you get something like this:

$git push -f origin master

Counting objects: 5, done.

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 323 bytes, done.

Total 3 (delta 1), reused 0 (delta 0)

Unpacking objects: 100% (3/3), done.

Enforcing Policies...

(refs/heads/master) (8338c5) (c5b616)

[POLICY] Your message is not formatted correctly

error: hooks/update exited with error code 1

error: hook declined to update refs/heads/master

To git@gitserver:project.git

! [remote rejected] master -> master (hook declined)

error: failed to push some refs to 'git@gitserver:project.git'

There are a couple of interesting things here. First, you see this where the hook starts running.

Enforcing Policies...

(refs/heads/master) (fb8c72) (c56860)

Remember that you printed that out at the very beginning of your update script. Anything your script echoes to stdout will be transferred to the client.

The next thing you’ll notice is the error message.

[POLICY] Your message is not formatted correctly

error: hooks/update exited with error code 1

error: hook declined to update refs/heads/master

The first line was printed out by you, the other two were Git telling you that the update script exited non-zero and that is what is declining your push. Lastly, you have this:

To git@gitserver:project.git

! [remote rejected] master -> master (hook declined)

error: failed to push some refs to 'git@gitserver:project.git'

You’ll see a remote rejected message for each reference that your hook declined, and it tells you that it was declined specifically because of a hook failure.

Furthermore, if someone tries to edit a file they don’t have access to and push a commit containing it, they will see something similar. For instance, if a documentation author tries to push a commit modifying something in the lib directory, they see

[POLICY] You do not have access to push to lib/test.rb

From now on, as long as that update script is there and executable, your repository will never have a commit message without your pattern in it, and your users will be sandboxed.

The downside to this approach is the whining that will inevitably result when your users' commit pushes are rejected. Having their carefully crafted work rejected at the last minute can be extremely frustrating and confusing; and furthermore, they will have to edit their history to correct it, which isn’t always for the faint of heart.

The answer to this dilemma is to provide some client-side hooks that users can run to notify them when they’re doing something that the server is likely to reject. That way, they can correct any problems before committing and before those issues become more difficult to fix. Because hooks aren’t transferred with a clone of a project, you must distribute these scripts some other way and then have your users copy them to their .git/hooks directory and make them executable. You can distribute these hooks within the project or in a separate project, but Git won’t set them up automatically.

To begin, you should check your commit message just before each commit is recorded, so you know the server won’t reject your changes due to badly formatted commit messages. To do this, you can add the commit-msg hook. If you have it read the message from the file passed as the first argument and compare that to the pattern, you can force Git to abort the commit if there is no match:

#!/usr/bin/env ruby

message_file = ARGV[0]

message = File.read(message_file)

$regex = /\[ref: (\d+)\]/

if!$regex.match(message)

puts "[POLICY] Your message is not formatted correctly"

exit 1

end

If that script is in place (in .git/hooks/commit-msg) and executable, and you commit with a message that isn’t properly formatted, you see this:

$git commit -am 'test'

[POLICY] Your message is not formatted correctly

No commit was completed in that instance. However, if your message contains the proper pattern, Git allows you to commit:

$git commit -am 'test [ref: 132]'

[master e05c914] test [ref: 132]

1 file changed, 1 insertions(+), 0 deletions(-)

Next, you want to make sure you aren’t modifying files that are outside your ACL scope. If your project’s .git directory contains a copy of the ACL file you used previously, then the following pre-commit script will enforce those constraints for you:

#!/usr/bin/env ruby

$user = ENV[ 'USER' ]

# [ insert acl_access_data method from above ]

# only allows certain users to modify certain subdirectories in a project

defcheck_directory_perms

access = get_acl_access_data( '.git/acl' )

files_modified = `git diff-index --cached --name-only HEAD` .split( " \n" )

files_modified.each do|path|

next ifpath.size == 0

has_file_access = false

access[$user].each do|access_path|

if!access_path || (path.index(access_path) == 0)

has_file_access = true

end

if!has_file_access

puts "[POLICY] You do not have access to push to #{ path }"

exit 1

end

end

end

check_directory_perms

This is roughly the same script as the server-side part, but with two important differences. First, the ACL file is in a different place, because this script runs from your working directory, not from your .git directory. You have to change the path to the ACL file from this

access = get_acl_access_data( 'acl' )

to this:

access = get_acl_access_data( '.git/acl' )

The other important difference is the way you get a listing of the files that have been changed. Because the server-side method looks at the log of commits, and, at this point, the commit hasn’t been recorded yet, you must get your file listing from the staging area instead. Instead of

files_modified = `git log -1 --name-only --pretty=format:'' #{ ref }`

you have to use

files_modified = `git diff-index --cached --name-only HEAD`

But those are the only two differences – otherwise, the script works the same way. One caveat is that it expects you to be running locally as the same user you push as to the remote machine. If that is different, you must set the $user variable manually.

One other thing we can do here is make sure the user doesn’t push non-fast-forwarded references. To get a reference that isn’t a fast-forward, you either have to rebase past a commit you’ve already pushed up or try pushing a different local branch up to the same remote branch.

Presumably, the server is already configured with receive.denyDeletes and receive.denyNonFastForwards to enforce this policy, so the only accidental thing you can try to catch is rebasing commits that have already been pushed.

Here is an example pre-rebase script that checks for that. It gets a list of all the commits you’re about to rewrite and checks whether they exist in any of your remote references. If it sees one that is reachable from one of your remote references, it aborts the rebase.