Created attachment 9865 [details] tcp dumps logs & conf I have debian 7 loaded with the new sernet 4.1.7 I got the same with archlinux and 4.1.7 also the same deb7, ubuntu 12.04 and centos with 4.1.6 Basically when you declare a btrfs share with vfs objects = btrfs you are unable to delete certain groups such as everybody. If you follow https://wiki.samba.org/index.php/Setting_up_a_home_share The first thing you will notive is that "Include inheritable permissions from the object's parent" isn't checked. What I did is created a brand new install of deb7 with the sernet 4.1.7 repo's Created two btrfs partitions and mounted on /samba/samba1 and /samba/samba2 smb.conf the [samba2] share contains the vfs objects = btrfs declaration. I have included log.smbd for operations. I joined the domain logged on with a windows 7 client. Share permissions work fine. On the samba1 share in security in the advanced I unticked "Include inheritable permissions from the object's parent" applied and copied a wireshark tcp dump and the log. Then on samba2 exactly the same but "Include inheritable permissions from the object's parent" isn't ticked to start with ignored that tried to remove everybody clicked apply and its back again. Again wireshark dump and corresponding log. then on samba1 removed everybody clicked apply no probs !?
I've not been able to reproduce this, but I do see from the network traces that some strange ACL behaviour is triggered. samba1-remove-everbody ====================== The samba1-remove-everbody trace shows the following DACL before it is set: No. Time Source Destination Protocol Length Info 256 33.949608 192.168.1.7 192.168.1.2 SMB2 278 GetInfo Response NT User (DACL) ACL Revision: NT4 (2) Size: 128 Num ACEs: 5 NT ACE: ... (Domain SID-Administrator), flags 0x00, Access Allowed, mask 0x001200a9 NT ACE: S-1-22-2-0 (), flags 0x00, Access Allowed, mask 0x001200a9 NT ACE: S-1-1-0 (Everyone), flags 0x03, Access Allowed, mask 0x001200a9 NT ACE: S-1-3-0 (Creator Owner), flags 0x0b, Access Allowed, mask 0x001f01ff NT ACE: S-1-3-1 (Creator Group), flags 0x0b, Access Allowed, mask 0x001200a9 The Everyone ACE is removed for the SetInfo request: No. Time Source Destination Protocol Length Info 269 33.972235 192.168.1.2 192.168.1.7 SMB2 326 SetInfo Request SEC_INFO/SMB2_SEC_INFO_00 File: NT User (DACL) ACL Revision: NT4 (2) Size: 108 Num ACEs: 4 NT ACE: S-1-22-2-0 (), flags 0x00, Access Allowed, mask 0x001200a9 NT ACE: S-1-3-0 (Creator Owner), flags 0x0b, Access Allowed, mask 0x001f01ff NT ACE: S-1-3-1 (Creator Group), flags 0x0b, Access Allowed, mask 0x001200a9 NT ACE: ... (Domain SID-Administrator), flags 0x00, Access Allowed, mask 0x001200a9 After being set, the DACL returned by Samba doesn't carry the Everyone ACE: No. Time Source Destination Protocol Length Info 282 34.014025 192.168.1.7 192.168.1.2 SMB2 258 GetInfo Response NT User (DACL) ACL Revision: NT4 (2) Size: 108 Num ACEs: 4 NT ACE: S-1-22-2-0 (), flags 0x00, Access Allowed, mask 0x001200a9 NT ACE: S-1-3-0 (Creator Owner), flags 0x0b, Access Allowed, mask 0x001f01ff NT ACE: S-1-3-1 (Creator Group), flags 0x0b, Access Allowed, mask 0x001200a9 NT ACE: ... (Domain SID-Administrator), flags 0x00, Access Allowed, mask 0x001200a9 samba2-remove-inheritance-everybody =================================== The samba2-remove-inheritance-everybody trace shows the following DACL before it is set: No. Time Source Destination Protocol Length Info 316 28.093962 192.168.1.7 192.168.1.2 SMB2 238 GetInfo Response NT User (DACL) ACL Revision: NT4 (2) Size: 88 Num ACEs: 3 NT ACE: ... (Domain SID-Administrator), flags 0x00, Access Allowed, mask 0x001200a9 NT ACE: S-1-22-2-0 (), flags 0x00, Access Allowed, mask 0x001200a9 NT ACE: S-1-1-0 (Everyone), flags 0x00, Access Allowed, mask 0x001200a9 The Everyone ACE is removed for the SetInfo request: No. Time Source Destination Protocol Length Info 405 45.024638 192.168.1.2 192.168.1.7 SMB2 286 SetInfo Request SEC_INFO/SMB2_SEC_INFO_00 File: NT User (DACL) ACL Revision: NT4 (2) Size: 68 Num ACEs: 2 NT ACE: ... (Domain SID-Administrator), flags 0x00, Access Allowed, mask 0x001200a9 NT ACE: S-1-22-2-0 (), flags 0x00, Access Allowed, mask 0x001200a9 After being set, the DACL returned by Samba still carries the Everyone ACE (without granting any permissions). Also, the DACL contains duplicate ACEs for the trustees listed in the SetInfo request: No. Time Source Destination Protocol Length Info 420 45.059947 192.168.1.7 192.168.1.2 SMB2 298 GetInfo Response NT User (DACL) ACL Revision: NT4 (2) Size: 148 Num ACEs: 5 NT ACE: ... (Domain SID-Administrator), flags 0x00, Access Allowed, mask 0x001f01ff NT ACE: S-1-22-2-0 (), flags 0x00, Access Allowed, mask 0x001200a9 NT ACE: S-1-22-2-0 (), flags 0x00, Access Allowed, mask 0x001200a9 NT ACE: ... (Domain SID-Administrator), flags 0x00, Access Allowed, mask 0x001f01ff NT ACE: S-1-1-0 (Everyone), flags 0x00, Access Allowed, mask 0x00000000
Apologies as its every time I set up vfs objects = btrfs be it debian, ubuntu or archlinux. Only thing in common is that I have been using virtualbox for Samba. BTRFS without vfs objects = btrfs works fine. Maybe something to do with virtualbox, apols for any wasted time.
(In reply to comment #2) > Apologies as its every time I set up vfs objects = btrfs be it debian, ubuntu > or archlinux. > > Only thing in common is that I have been using virtualbox for Samba. > > BTRFS without vfs objects = btrfs works fine. > > Maybe something to do with virtualbox, apols for any wasted time. I don't understand. Do you mean that you hit this issue on any platform, as long as "vfs objects = btrfs" is set in smb.conf? I'm still not convinced that this issue is caused by vfs_btrfs. The Samba1 and Samba2 captures show a different ACL applied to the file before it is set (without the everyone ACE). Were both /samba/samba1/ and /samba/samba2/ paths located on a btrfs filesystem? Please run the test again using exactly the same ACL at each step, with the *only* difference being that one is on a vfs_btrfs enabled share, and one is on a default share (vfs_default).
(In reply to comment #3) Must be virtual box as yes every time on various distro's when the share is set up with vfs objects = btrfs I have problems. I can tell straight away as the tickbox for inherit parents objects is unticked before I do anything. Its always the same with virtual box, must be that if you can not recreate. I have done this maybe 10 times now. Will try again. > (In reply to comment #2) > > Apologies as its every time I set up vfs objects = btrfs be it debian, ubuntu > > or archlinux. > > > > Only thing in common is that I have been using virtualbox for Samba. > > > > BTRFS without vfs objects = btrfs works fine. > > > > Maybe something to do with virtualbox, apols for any wasted time. > > I don't understand. Do you mean that you hit this issue on any platform, as > long as "vfs objects = btrfs" is set in smb.conf? > > I'm still not convinced that this issue is caused by vfs_btrfs. The Samba1 and > Samba2 captures show a different ACL applied to the file before it is set > (without the everyone ACE). > Were both /samba/samba1/ and /samba/samba2/ paths located on a btrfs > filesystem? > > Please run the test again using exactly the same ACL at each step, with the > *only* difference being that one is on a vfs_btrfs enabled share, and one is on > a default share (vfs_default).
(In reply to comment #4) Also /samba/samba1/ and /samba/samba2/ where identical only thing different was vfs objects in samba2. I added the fstab and smb.conf to files supplied if you want to check. > (In reply to comment #3) > Must be virtual box as yes every time on various distro's when the share is set > up with vfs objects = btrfs I have problems. > I can tell straight away as the tickbox for inherit parents objects is unticked > before I do anything. > Its always the same with virtual box, must be that if you can not recreate. > I have done this maybe 10 times now. > > Will try again. > > > (In reply to comment #2) > > > Apologies as its every time I set up vfs objects = btrfs be it debian, ubuntu > > > or archlinux. > > > > > > Only thing in common is that I have been using virtualbox for Samba. > > > > > > BTRFS without vfs objects = btrfs works fine. > > > > > > Maybe something to do with virtualbox, apols for any wasted time. > > > > I don't understand. Do you mean that you hit this issue on any platform, as > > long as "vfs objects = btrfs" is set in smb.conf? > > > > I'm still not convinced that this issue is caused by vfs_btrfs. The Samba1 and > > Samba2 captures show a different ACL applied to the file before it is set > > (without the everyone ACE). > > Were both /samba/samba1/ and /samba/samba2/ paths located on a btrfs > > filesystem? > > > > Please run the test again using exactly the same ACL at each step, with the > > *only* difference being that one is on a vfs_btrfs enabled share, and one is on > > a default share (vfs_default).
(In reply to comment #5) > (In reply to comment #4) > > Also /samba/samba1/ and /samba/samba2/ where identical only thing different was > vfs objects in samba2. Ok, looks like your ACLs are coming from an extended attribute in the case of /samba/samba1, which explains why it retains the removal of the Everyone ACE. log.smbd-samba1-remove-everybody: [2014/04/22 13:41:16.466517, 10, pid=3678, effective(0, 100), real(0, 0)] ../source3/smbd/smb2_getinfo.c:271(smbd_smb2_getinfo_send) smbd_smb2_getinfo_send: . - fnum 239537848 [2014/04/22 13:41:16.466566, 10, pid=3678, effective(0, 100), real(0, 0), class=vfs] ../source3/modules/vfs_acl_common.c:391(get_nt_acl_internal) get_nt_acl_internal: name=. ... [2014/04/22 13:41:16.467094, 10, pid=3678, effective(0, 100), real(0, 0), class=vfs] ../source3/modules/vfs_acl_common.c:491(get_nt_acl_internal) get_nt_acl_internal: blob hash matches for file . The /samba/samba2/ share however goes straight to the POSIX ACL code path. log.smbd-samba2-remove-inheritance-everybody: [2014/04/22 13:37:05.653511, 10, pid=3642, effective(0, 100), real(0, 0)] ../source3/smbd/smb2_getinfo.c:271(smbd_smb2_getinfo_send) smbd_smb2_getinfo_send: . - fnum 2184804280 [2014/04/22 13:37:05.653553, 10, pid=3642, effective(0, 100), real(0, 0), class=acls] ../source3/smbd/posix_acls.c:3486(posix_fget_nt_acl) posix_fget_nt_acl: called for file .
(In reply to comment #6) > Ok, looks like your ACLs are coming from an extended attribute in the case of > /samba/samba1, which explains why it retains the removal of the Everyone ACE. ... > The /samba/samba2/ share however goes straight to the POSIX ACL code path. @Stuart, with this in mind, could you please retest with vfs_acl_xattr explicitly configured alongside vfs_btrfs? smb.conf share configuration would then be: [samba1] path = /samba/samba1/ read only = No ... [samba2] path = /samba/samba2/ read only = No vfs objects = btrfs acl_xattr Please recreate the /samba/samba2/ and /samba/samba1/ paths prior to testing, to ensure that any existing ACLs/xattrs are wiped.
Ah, looks like this is specific to when Samba is running as an AD domain controller. Basically, if Samba is running as a domain controller and the "vfs objects" parameter is not set, then the acl_xattr module is enabled. Otherwise, the "vfs objects" configuration is left as-is. This kind of wacky behaviour should be documented in the smb.conf "vfs objects" section at the very least. 3343 static void init_locals(void) 3344 { 3345 /* 3346 * We run this check once the [globals] is parsed, to force 3347 * the VFS objects and other per-share settings we need for 3348 * the standard way a AD DC is operated. We may change these 3349 * as our code evolves, which is why we force these settings. 3350 * 3351 * We can't do this at the end of lp_load_ex(), as by that 3352 * point the services have been loaded and they will already 3353 * have "" as their vfs objects. 3354 */ 3355 if (lp_server_role() == ROLE_ACTIVE_DIRECTORY_DC) { 3356 const char **vfs_objects = lp_vfs_objects(-1); 3357 if (!vfs_objects || !vfs_objects[0]) { 3358 if (lp_parm_const_string(-1, "xattr_tdb", "file", NULL)) { 3359 lp_do_parameter(-1, "vfs objects", "dfs_samba4 acl_xattr xattr_tdb"); 3360 } else if (lp_parm_const_string(-1, "posix", "eadb", NULL)) { 3361 lp_do_parameter(-1, "vfs objects", "dfs_samba4 acl_xattr posix_eadb"); 3362 } else { 3363 lp_do_parameter(-1, "vfs objects", "dfs_samba4 acl_xattr"); 3364 } 3365 } 3366 3367 lp_do_parameter(-1, "map hidden", "no"); 3368 lp_do_parameter(-1, "map system", "no"); 3369 lp_do_parameter(-1, "map readonly", "no"); 3370 lp_do_parameter(-1, "map archive", "no"); 3371 lp_do_parameter(-1, "store dos attributes", "yes"); 3372 } 3373 }
Created attachment 9894 [details] warn if AD DC required "vfs objects" are not present in explicit config definitions
Is this a showstopper for 4.2.0?
This is only a configuration enhancement. No 4.2.0 blocker.
Looks like the patch never got reviewed here. I've rebased it and will submit it to the list today for feedback, as I still think it's something worth addressing.
fixed in master with 03b42aeb811ae7260a9a9e197212767877484a78