title: How to change Unix permissions when I don't own the file but do have write permission on the directory?
body: <p>I'm sharing a git repository with a colleague, and because git does not propagate the full panoply of Unix file permissions, we have a "hook" that runs on update which sets the 'other' permissions as they need to be set.  The problem?  The hook uses <code>chmod</code>, and it turns out that when my colleague commits a file, he owns it, so I can't run <code>chmod</code> on it, and vice versa.  The directories are all group writable, sticky, so I believe that either of us has the right to remove any file and replace it with one of the same name, same contents, but different ownership.  Presumably then we could <code>chmod</code> it.  But this seems like an awfully big hammer, and I'm a bit leery of screwing it up.  So, two questions:</p>
  
  <ol>
  <li><p>Can anybody think of another way to do it?</p></li>
  <li><p>If not, what's the best design for a <strong>bulletproof</strong> shell script that implements "make this file belong to me"?  No cross-filesystem moves, etc etc...</p></li>
  </ol>
  
  <p>For those who may not have realized, write permission does not confer permission to <code>chmod</code>:</p>
  
  <pre><code>% ls -l value.c
  -rw-rw---- 1 agallant ta105 133 Feb 10 13:37 value.c
  % [ -w value.c ] &amp;&amp; echo writeable
  writeable
  % chmod o+r value.c               
  chmod: changing permissions of `value.c': Operation not permitted
  </code></pre>
  
  <p>We are both in the <code>ta105</code> group.</p>
  
  <hr>
  
  <p>Notes: </p>
  
  <ol>
  <li><p>We're using <code>git</code> not only to coordinate changes but to publish the repo as a course web site.  Publishing the web site is the primary purpose of the repo. The permissions script runs at every update using a git hook, and it ensures that students do not have permission to read solutions that have not yet been unveiled.</p></li>
  <li><p>Please do not suggest that I have the wrong umask.  Not all files in the repo should have the same permissions, and whatever umask is chosen, permissions on some files will need to be changed.   Not to mention that it would be discourteous for me to impose my umask preferences on my colleagues.</p></li>
  <li><p><strong>UPDATE</strong>: I've just learned that in our environment, root is quashed to <code>nobody</code> on all machines we have access to, so that a solution which relies on root privileges won't work.</p></li>
  </ol>