Setgid not preserved in GFS2 with ACL

[Nicolas Ecarnot]

[Sorry for cross-posting, but I sincerely don't know who's best to answer]

Hi,

Using many production Samba file servers on RHEL 5.6 for a while, we are 
now finishing to setup a samba cluster on Ubuntu-server (oneiric) with 
cman+clvm+GFS2+ctdb.

Like on our other samba setups, we are using ACLs and we set up the 
setgid bit on our folders (chmod g+s folder), as well as default ACL.
The access rights are managed via the basic windows explorer security 
tab and is working nicely.

But on this new GFS2, I observe that this is not working the same.

To make it short, the setgid bit gets lost when a user creates a subdir.

To be precise, here is what I'm observing :

My folder looks like this :

root at server:/foo/bar# getfacl .
# file: .
# owner: root
# group: adminsGroup
# flags: ss-
user::rwx
group::rwx
group:domainUsers:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:domainUsers:rwx
default:mask::rwx
default:other::---

* When the user root runs 'mkdir rootDir', this directory correctly gets 
the adequate rights, and it gets the setgid bit (allowing deeper 
inheritance to keep working).

* When a non-root user belonging to the adminsGroup group runs 'mkdir 
privDir', the directory also gain the same feature as above.

* When a basic non-root user belonging to the domainUsers group runs 
'mkdir basicDir', it gets created (the ACL allows it) but the setgid bit 
is *NOT* preserved.



My tests are showing that with ext3 and ext4, on the same server (and/or 
on other systems), this behavior is different, and that the sgid bit is 
preserved.

I have added the suiddir flag when mounting the GFS2 partition, but this 
does not improve anything.


May someone tell me :
- if this new behavior is faulty or expected?
- if these mailing-lists are the best place to ask such questions? 
(ubuntu-server at lists.ubuntu.com + cluster-devel at redhat.com), and if 
needed advice me a better place
- if this is unexpected, if I should file a bug? (and where)

Thank you.

-- 
Nicolas Ecarnot