Hi, I have discovered a bug when using CIFS mounted shares from Samba4 on a Linux machine. We use custom ACLs to allow certain groups extra access to home shares, setting 'user:staff:r-x' using setfacl, along with the related 'default' ACL so that it propagates to newly created directories. For this to work, we also set 'mask::rwx'. These shares have group and other permissions completely restricted, seen by the getfacl command as 'group::---,other::---'. When such a share is mounted on a Linux client running Samba3, the ACLs can be seen due to UNIX extensions and are correct. The issue is however that members of the same group that owns the file (which should have no access) is given the same access as the 'mask' ACL, allowing them to read, write, delete and execute the file. Replicating this same test in /tmp on the Linux machine yields the correct results - a member of the same group only gets the permissions defined in the 'group' ACL. I'm not sure if this is a problem with Samba4 on the server or Samba3 on the client, or a problem with our configuration, but this isn't the expected behaviour of extended ACLs. We use Samba4 version 4.1.5 and Samba3 client version 3.6.3. Both the server and client are running Ubuntu 12.04 LTS. Robin McCorkell Karoshi Client maintainer, The Linux Schools Project http://www.linuxschools.com https://github.com/the-linux-schools-project
On Fri, Feb 28, 2014 at 10:16:52AM +0000, Robin McCorkell wrote:> Hi, > > I have discovered a bug when using CIFS mounted shares from Samba4 on a > Linux machine. We use custom ACLs to allow certain groups extra access to > home shares, setting 'user:staff:r-x' using setfacl, along with the related > 'default' ACL so that it propagates to newly created directories. For this > to work, we also set 'mask::rwx'. These shares have group and other > permissions completely restricted, seen by the getfacl command as > 'group::---,other::---'. > > When such a share is mounted on a Linux client running Samba3, the ACLs can > be seen due to UNIX extensions and are correct. The issue is however that > members of the same group that owns the file (which should have no access) > is given the same access as the 'mask' ACL, allowing them to read, write, > delete and execute the file. Replicating this same test in /tmp on the > Linux machine yields the correct results - a member of the same group only > gets the permissions defined in the 'group' ACL. > > I'm not sure if this is a problem with Samba4 on the server or Samba3 on > the client, or a problem with our configuration, but this isn't the > expected behaviour of extended ACLs. We use Samba4 version 4.1.5 and Samba3 > client version 3.6.3. Both the server and client are running Ubuntu 12.04 > LTS.Log a bug at bugzilla.samba.org please with explicit instructions on how to reproduce. I'll take a look once I have a reproducible test case. Thanks, Jeremy.
Apparently Analagous Threads
- Samba4 LDAP ACLs - access to POSIX attributes from a non-admin account
- [Bug 1236] New: Services list is confusingly different from the /etc/services
- Can't join new samba dc to existing dc
- Samba4 Winbind - is it really not possible to be sensible?
- Can't join new samba dc to existing dc