File Permissions, Persisting the SETGID bit.

Question

I was experimenting with permissions and I noticed something about the setgid bit and was hoping someone could help me understand if there's a way to change the behavior. The situation is that when a file is edited by the group member the SETGID bit is erased, and I'm trying to figure out a way to have that bit persist through file modifications.
So for example;
There exists a file with an ownership such as [user1:user2], and the file permissions are [2770].
The directory itself has +t set, [1770].
+ If user1 modifies the file, then permissions remain [2770].
+ If user2 modifies the file, then permissions revert to [0770].
So, is there anything I can do to allow user2 to edit the file without losing the [2770] permissions on the file?
Thanks,
Last edited by theoddsarebad (2012-12-20 15:12:19)

Answer 1

$ chmod 2760 file
That allowed user2 to modify the file without permissions being stripped, but it didn't allow effective [g|s]id's to become user2's when user1 executes the file. So close.
And considering the following, I guess you're right, ACL's are the only option left to explore.
Linux source code: filemap.c
* The logic we want is
* if suid or (sgid and xgrp)
* remove privs
int should_remove_suid(struct dentry *dentry)
mode_t mode = dentry->d_inode->i_mode;
int kill = 0;
/* suid always must be killed */
if (unlikely(mode & S_ISUID))
kill = ATTR_KILL_SUID;
* sgid without any exec bits is just a mandatory locking mark; leave
* it alone. If some exec bits are set, it's a real sgid; kill it.
if (unlikely((mode & S_ISGID) && (mode & S_IXGRP)))
kill |= ATTR_KILL_SGID;
if (unlikely(kill && !capable(CAP_FSETID)))
return kill;
return 0;
Yay, dead end with that, at least a good bit was learned about the nuances of file perms. Time to move on to ACL's. : )
Last edited by theoddsarebad (2012-12-20 17:19:57)