Bug 10560 - explicit AD DC "vfs objects" definitions result in permissions issues
explicit AD DC "vfs objects" definitions result in permissions issues
Status: NEEDINFO
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules
4.1.7
All All
: P5 normal
: 4.3
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-22 13:00 UTC by Stuart Ian Naylor
Modified: 2014-11-29 10:26 UTC (History)
3 users (show)

See Also:


Attachments
tcp dumps logs & conf (296.94 KB, application/octet-stream)
2014-04-22 13:00 UTC, Stuart Ian Naylor
no flags Details
warn if AD DC required "vfs objects" are not present in explicit config definitions (2.71 KB, patch)
2014-05-02 16:50 UTC, David Disseldorp
ddiss: review? (abartlet)
asn: review? (metze)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stuart Ian Naylor 2014-04-22 13:00:36 UTC
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 !?
Comment 1 David Disseldorp 2014-04-28 08:31:28 UTC
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
Comment 2 Stuart Ian Naylor 2014-04-28 08:51:23 UTC
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.
Comment 3 David Disseldorp 2014-04-28 09:01:53 UTC
(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).
Comment 4 Stuart Ian Naylor 2014-04-28 10:09:45 UTC
(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).
Comment 5 Stuart Ian Naylor 2014-04-28 10:12:49 UTC
(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).
Comment 6 David Disseldorp 2014-04-28 12:04:30 UTC
(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 .
Comment 7 David Disseldorp 2014-04-28 12:17:57 UTC
(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.
Comment 8 David Disseldorp 2014-04-28 12:37:00 UTC
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 }
Comment 9 David Disseldorp 2014-05-02 16:50:29 UTC
Created attachment 9894 [details]
warn if AD DC required "vfs objects" are not present in explicit config definitions
Comment 10 Karolin Seeger 2014-11-27 10:56:09 UTC
Is this a showstopper for 4.2.0?
Comment 11 Stefan Metzmacher 2014-11-29 10:26:31 UTC
This is only a configuration enhancement.
No 4.2.0 blocker.