1

Is it possible with the normal Unix permissions system to enable group members to have the right to change a file's permissions?

In other words, suppose we have a file awesome.rb which is owned by user brandon who belongs to group developers, and user darryl (also a member of developers) needs to make a particular file executable. Is there any way to make this possible?

  • 1
    To delete a file, you don't need any permissions on the file itself. You need write permission on the directory containing the file. If you have that, you can delete a file you can't even read. – cjm May 14 '13 at 19:19
  • ahh... I knew you had to have write permissions on the directory before you could delete things in it, but I didn't realize that the permissions on the file were irrelevant. Thanks. I'm editing the question to reflect the fact that deletion is a different matter entirely. – iconoclast May 14 '13 at 19:22
  • 1
    Tools like rm will usually warn you before deleting a file you don't have write permission for, but that's a UI thing. The underlying unlink call doesn't care. – cjm May 14 '13 at 19:23
  • 1
    Adding to cjm's comment: Using the "sticky-bit" (chmod o+t) on a directory will modify the behavior of world-writable directories (like /tmp); preventing users from removing files they don't own themselves, even though they have write-permission to the directory (and thus should be able to remove any file). But still, it doesn't matter if the user has read and/or write permission to the actual file. – Baard Kopperud May 15 '13 at 6:51
1

They can have permissions to delete files, so long as they have write permissions on the directory the files are inside. Only the owner can change the permissions using normal Unix permissions.

NOTE: If you're a member of a group and the permissions on the file are rwx, the members of the group can edit the file and execute it, nothing more. The rest of the permissions are keyed off of the directories permissions.

Example

$ groups
saml tmux vboxusers jupiter

# have write perms on dir
$ ls -dl ../somedir/
drwxrwx--- 2 root tmux 4096 May 14 15:36 ../somedir/

$ ls -l 
-rw-rw---- 1 root tmux 0 May 14 15:36 somefile

# can delete file
$ rm somefile
$

# don't have write perms on dir
$ ls -ld ../somedir/
drwxr-x--- 2 root tmux 4096 May 14 15:39 ../somedir/

$ ls -l
-rw-rw---- 1 root tmux 0 May 14 15:39 somefile

# can't delete file 
$ rm somefile 
rm: cannot remove `somefile': Permission denied

# can't move file either
$ mv somefile /tmp/
mv: cannot remove `somefile': Permission denied

Using Access Control Lists (ACLs) you can create more complex and flexible permissions.

References

| improve this answer | |
0

Unfortunately, managing a file's security is considered the job of whoever the owning user is. Short of doing a chmod u+s /bin/chown or giving the target users CAP_CHOWN via pam_cap.so (both of which would give them root-level chowning rights for all files on the system, that's as dangerous as it sounds), the owning user and root are the only people who can touch it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.