on debian lenny system, user1 in group1 have a folder folder1 in his home directory owned by group2 whith sgid bit set drwxrws--- 2 user1 group2 4096 mar 9 18:01 folder1 if this folder is renamed to folder1b via homes share the sgid bit is lost drwxrwx--- 2 user1 group2 4096 mar 9 18:01 folder1b this does not happen if the folder is owned by group1 i also tried samba 3.5.6 (backport lenny) and samba 3.5.8 (sernet-samba), but the problem is still there this completely breaks the sgid effect on the directory for file sharing...
You don't happen to have XFS as your file system? Volker
no the filesystem is ext3
and it happens only if user1 is not member of group2
i have just enable audit module which logs chmod ./folder1b mode 0x5f8 0x5f8=2770... but perms are drwxrwx---
Ok, reproduced it. Jeremy, I think this is essentially a duplicate of 7987. You asked whether that one is reproducable without Windows. This one is. Just set up a share with chmod 2770 permissions. Log in with smbclient, do a "mkdir foo". Foo will also have the sgid bit set. Do a "ren foo bar", and bar will have lost the sgid bit. Volker
after activating "store dos attribute", the sgid bit is not lost after directoy rename. so there must be a link with the way the dos mode is handled (even if this bit is not theoricaly mapped to any dos attribute) i tried to have a look at the source but did not really find any explanation...
Reproduced in master. I'll take a closer look - thanks ! Jeremy.
Testing a fix for this now. More when it passes. Jeremy.
Created attachment 6340 [details] git-am fix for 3.5.next Fix for 3.5.next. Volker, please check. I have a more extensive fix for master and 3.6.0. Jeremy.
Question: Why do we have to do any kind of chmod on rename at all? Doing it as root seems very kludgy and dangerous to me? Volker
This chown is for storing the ARCHIVE bit in the unix mode bits, which we need to set on rename. This code path isn't taken if we're storing DOS attributes in an EA, which is why it took so long to track down and reproduce (I normally run with DOS attrs in an EA). If we're going to do this chown, we either have to note that it obeys the SETGID restriction (i.e. if you're not a group member you'll lose it) or we have to do it as root. Sucks, but them's the breaks :-). Jeremy.
Created attachment 6360 [details] git-am fix for 3.5.next After consultation with Volker, don't use the become_root() trick, but simply deny this inside file_set_dosmode(). Jeremy.
Comment on attachment 6360 [details] git-am fix for 3.5.next Looks good, thanks! The reasons to refuse doing this that we have a workaround with "store dos attributes = yes"
Pushed patch to v3-5-test. Will be included in the next Samba 3.5 bug fix release. Closing out bug report. Please feel free to re-open if this needs to be fixed for Samba 3.4 also. Thanks!