How to change Unix permissions when I don't own the file but do have write permission on the directory?

Question

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 chmod, and it turns out that when my colleague commits a file, he owns it, so I can't run chmod 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 chmod it. But this seems like an awfully big hammer, and I'm a bit leery of screwing it up. So, two questions:

1. Can anybody think of another way to do it?

2. If not, what's the best design for a bulletproof shell script that implements "make this file belong to me"? No cross-filesystem moves, etc etc...

For those who may not have realized, write permission does not confer permission to chmod:

% ls -l value.c
-rw-rw---- 1 agallant ta105 133 Feb 10 13:37 value.c
% [ -w value.c ] && echo writeable
writeable
% chmod o+r value.c               
chmod: changing permissions of `value.c': Operation not permitted

We are both in the ta105 group.

---

Notes:

1. We're using git 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.

2. 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.

3. UPDATE: I've just learned that in our environment, root is quashed to nobody on all machines we have access to, so that a solution which relies on root privileges won't work.

Solution 1

There is at least one Unix in which I've seen a way to give someone chmod and chown permissions on all files owned by a particular group. This is sometimes called "group superuser" or something similar.

The only Unix I'm positive I've seen this on was the version of Unix that the Encore Multimax ran.

I've searched a bit, and while I remember a few vague references to an ability of this sort in Linux, I have been unable to find them. So this may not be an option. Luckily, it can be simulated, albeit the simulation is a bit dangerous.

The way to simulate this is to make a very specific suid program that will do the chmod as root after checking that you are a member of the same group as owns the file, and your username is listed as having that permission in a special /etc/chmod_group file that must be owned by root and readable and writeable only by root.

Solution 2

The most straightforward way to do this is to make your partner and you members of a new group (let's say "devel"), and have that as the group of the file. That way it can be owned by either of you, and as long as the group is right, you can both work with it.

If that doesn't work with you, "sudo" can be configured such that only those two users can run a chmod command on files in that specific directory as root with no password.

Solution 3

If you set your umask correctly, the files could be created with the correct permissions in the first place:

$ umask 0022
$ touch foo
$ ls -l foo
-rw-r--r-- 1 sarnold sarnold 0 2011-02-20 21:17 foo
$ rm foo
$ umask 0002
$ touch foo
$ ls -l foo
-rw-rw-r-- 1 sarnold sarnold 0 2011-02-20 21:17 foo

Comments

[Norman Ramsey]

That's exactly the situation we're in. Write permission is not chmod permission. I don't know if the admins will allow or support sudo, but it's worth looking into.

[Norman Ramsey]

Sorry, but emacs knows only one umask, and the correct default for my installation is 002. The whole point of the question is how to deal with the few files for which the default umask is not appropriate.

[Norman Ramsey]

We both need to chmod, and if two of us run this code at once, value.c is hosed.

[Norman Ramsey]

It's a nice thought. I've edited the question to reflect that the primary purpose of the repo is to be published as a course web site. Setting appropriate permissions for the web site is where we run into trouble.

[Norman Ramsey]

I'm not sure my sysadmins will go for the suid program---I'll have to ask them. But your suggestion seems the most safe and sane of the ones I've seen so far.

[Omnifarious]

@Norman Ramsey: It may be possible to use SELinux or something similar to give the program very narrow capabilities. I also know there's an effort in Fedora 15 to get rid of setuid programs all together, which indicates there's an alternate mechanism now for accomplishing a similar thing in a more controlled way.

[mindas]

+1 for sudo. Simply wrap your chmod into a bash script and define sudo rules for it.

[sarnold]

@Normal Ramsey, Ah! I didn't realize that you only wanted the different permissions for a handful of files; I thought they were all wrong. :)

[sarnold]

@Omnifarious, the setuid-root programs are gradually going to be replaced with specific posix draft capabilities(7) to specify which subset of root privileges are going to be granted to the program. You can get started now :) by using the setcap(8) utility to grant e.g. CAP_DAC_OVERRIDE and not allow CAP_NET_BIND or CAP_SYS_ADMIN, etc.

[Noufal Ibrahim]

Is your course material published directly as a git repo? I'm not clear on how your permission system would work with such a thing. Git repositories can only be cloned entirely and your students would have access to the whole content no?

[Kimvais]

Actually, what I said about EXT, does not seem to be true - at least on Debian Squeeze, the g+s seems to do the trick.

[Norman Ramsey]

students can't get access to the central repo. There's only one replica that students have access to, and that replica can be written only by instructors. So the workflow is that every push to the (private) central repo runs a hook that updates the public repo. Part of that hook sets permissions.

[Noufal Ibrahim]

Ah okay. Wouldn't it be possible then to have something like an answered branch which contains only what the students should be allowed to see? That way, you don't have to worry about permissions since even if they clone the whole public repo, they won't get the matter that they're not supposed to.

[Norman Ramsey]

My publishing hook just does a 'git pull' to the public copy, then runs 'make' to derive files and set permissions. Maybe the solution is to run the deploy script setuid in some way; I don't know.

[Norman Ramsey]

We have group ownership. The problem is that on Unix, group ownership conveys permission to write, but it does not convey permission to change permissions!

[Norman Ramsey]

I've marked this answer accepted because (a) I believe a setuid program might help substantially, and (b) it's the answer that gave me the most new ideas to think about. The problem remains unsolved.

[Omnifarious]

@Norman Ramsey: Thanks. I may research the capability thing that @sarnold mentioned, and if I do and I still remember this question, I will come here and update it with a description of how to accomplish the task using them. I think they are an even better idea than the setuid program.

[Omnifarious]

I don't think there's any better chance you'll get all the rules in sudo right than there is you'll get a suid program written in C to do the right thing. In fact, I think there's a worse chance. The way you express rules in sudo is rather arcane.

[Norman Ramsey]

@Omnifarious. Shit. You didn't get your bounty. User error. I've asked for moderator help.

[Andrew Aylett]

So you're publishing the working copy directly, rather than actually deploying it somewhere? Your workflow may be improved by making the deploy step put the files elsewhere, even if that just means putting the git repository in a subdirectory with no read access for students and using rsync to copy the files out into the parent, with the right permissions for the students.

[Omnifarious]

@Norman Ramsey: So far, the result of that seems to be the loss of about 300 reputation points. grin But, perhaps there is another reason that happened. I'm not hugely concerned, but thank you!

[Miquel]

You're right, sorry. Only the owner can chmod a file. Group permissions aren't enough.

[R.. GitHub STOP HELPING ICE]

This is roughly the right approach, but the temp name should be generated in a safe manner, and the cmp is probably unnecessary as long as you check exit status (which you need to be doing).