18

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.

Improve this question
3
  • Sorry, mods don't have the ability to change which answer is accepted and which answer gets the bounty. Commented Feb 28, 2011 at 13:48
  • I am probably missing some part of your full scenario, but it appears you should be looking at the directory permissions. The ability to modify permissions for a file is inferred from the mode setting on the directory the file is in. You didn't show the settings on this directory. Are they drwxrwxr_x or something like that? You probably want drwxrwsr_x. Your current directory permissions would help to clarify. Commented Apr 23, 2013 at 4:31
  • @AmitNaidu according to man 2 chmod, you need to be the owner or the superuser to change a file's permissions. The parent directory's permissions aren't mentioned, and seem like they should be irrelevant as the permissions are stored in the inode, not in the directory (otherwise two hard links to the same file could have different permissions). Commented Dec 17, 2013 at 15:12

8 Answers 8

Reset to default
8

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

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.
@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.
@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.
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.
@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.
|
3

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.

Improve this answer

3 Comments

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.
+1 for sudo. Simply wrap your chmod into a bash script and define sudo rules for it.
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.
2
+75

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
Improve this answer

2 Comments

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.
@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. :)
0

I'm taking a step back. Let me know if I'm violating some restriction in your system I haven't read.

From your question, I assume you're trying to share a git repository using file:// URLs and relying on the UNIX filesystem permissions to take care of authorisation etc. Why don't you consider another way to share your repositories that doesn't involve this hassle?

I can think of two ways.

  • You can create bare repository on either of your machines, add that as a remote to your working repos and use it to collaborate. Serving it can be done using the inbuilt git daemon command. Detais are here. This will however not give you any access control.
  • You can install gitosis locally and use that to serve your repository. This allows a simple access control system so that you can restrict/allow certain users.

There was a related question that came up a while ago that might be relevant. git daemon worked for him - Administrating a git repo without root permissions

I also found something on server fault that might be relevant to your problem - https://serverfault.com/questions/21126/git-daemon-and-access-control-for-multiple-repos

Improve this answer

4 Comments

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.
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?
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.
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.
0

Probably not the most elegant way, but it seems to work

$ umask 0002 $ mv value.c value.c.tmp $ cat value.c.tmp > value.c $ rm value.c.tmp

one could argue that it could be made bulletproof, but then someone brings along a RPG...

If both of you need to chmod, I can not think of another way - if it is OK that YOU can chmod but no the other guy, you can chmod 6770 . or chmod g+s,u+s . in the directory (e.g. set SUID and GUID bits) so the one that owns the directory will always be the owner of the files. Unfortunately some (if not most), namely EXT2/3/4 ignore the SUID bit.

Of course, setting the umask to 0002 will solve the problem by not making it mandatory.

Improve this answer

2 Comments

We both need to chmod, and if two of us run this code at once, value.c is hosed.
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.
0

Assuming that your publishing hook actually deploy files, rather than just setting permissions in the working copy, you could deploy to a temporary location then use rsync to ensure that the file contents and permissions are correct.

Slightly nicer, but requiring some infrastructure which I'm guessing isn't in place, would be to ensure that the deploy script only runs under one user. You could do this using sudo, if your sysadmins allow, or by setting up a git server service, like gerrit, or even by having a cron job run every five minutes which checks for updates and deploys if necessary.

Improve this answer

2 Comments

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

This might work:

touch $name.tmp chmod 660 $name.tmp cp $name $name.tmp if cmp $name $name.tmp 2>/dev/null; then rm $name && \ cp $name.tmp $name && \ rm $name.tmp fi

It's just a variation of your original idea

Improve this answer

1 Comment

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).
0

Ok, a mixture of things that build on previous answers:

  • you can set the umask of a folder if you mount it at fstab. If you could agree with people to work on that mount, you could enforce g+w

  • If you set the group-id bit of that folder (g+s) all files will belong to the group the folder belongs to, so the group ownership of the file propagates

Is that doable? Of course enforcing that mount point is no easy task. Any better ideas around that one anyone?

Improve this answer

2 Comments

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!
You're right, sorry. Only the owner can chmod a file. Group permissions aren't enough.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.