samba - Nov 2018 - "missing security tab" and related ACL issues

On Fri, 9 Nov 2018 15:39:55 +0100
"Stefan G. Weichinger via samba" <samba at lists.samba.org>
wrote:
> Am 09.11.18 um 09:06 schrieb Stefan G. Weichinger via samba:
> 
> > We still saw now security tab fpr samba shares in Windows. Not as
> > domain-admin, not as member of a user with the needed privilege.
> > 
> > The security tab is there for local drives and
> > windows-server-shares, only samba-4.8.6-shares miss it.
> > 
> > I will recheck everything ...
> 
> 
> 
> # smbd -b | grep HAVE_LIBACL
>    HAVE_LIBACL
> samba ~ # testparm -sv | grep -i acl
> 
> Server role: ROLE_DOMAIN_MEMBER
> 
> 	acl allow execute always = Yes
> 	acl check permissions = Yes
> 	acl group control = No
> 	acl map full control = Yes
> 	force unknown acl user = Yes
> 	inherit acls = No
> 	map acl inherit = Yes
> 	nt acl support = No
> 	vfs objects = acl_xattr full_audit
> 	acl map full control = No
> 	acl map full control = No
> 
> interesting, 3 lines with "acl map full control"
> 
> I have 2 shares with "acl map full control = No"
> 
> is it possible that this is somehow read serially and influences
> shares below as well? I know that behavior from other software.
> 
No, the parameters set on share only affect that share,and they
override global settings.

Can I make some suggestions ?

If this isn't in [global], move it there:

        map acl inherit = Yes

Remove these lines where ever they occur, they are default settings:

	acl check permissions = Yes
	acl group control = No
	acl map full control = Yes
	inherit acls = No

I would remove these, I am sure you don't really need them:

	force unknown acl user = Yes
	nt acl support = No
	acl map full control = No

I would also remove this line, as you have it set, any executable can
be run, even if it isn't set as an executable:

	acl allow execute always = Yes

If you have any concerns about removing these lines, I suggest you
read 'man smb.conf', I think you will see why I suggest removing the
lines ;-)

Rowland

Am 09.11.18 um 17:13 schrieb Rowland Penny via samba:
>> I have 2 shares with "acl map full control = No"
>>
>> is it possible that this is somehow read serially and influences
>> shares below as well? I know that behavior from other software.
>>
> 
> No, the parameters set on share only affect that share,and they
> override global settings.
great
> Can I make some suggestions ?
sure, that's why I am here
> If this isn't in [global], move it there:
> 
>          map acl inherit = Yes
> 
> Remove these lines where ever they occur, they are default settings:
> 
> 	acl check permissions = Yes
> 	acl group control = No
> 	acl map full control = Yes
> 	inherit acls = No
> 
> I would remove these, I am sure you don't really need them:
> 
> 	force unknown acl user = Yes
> 	nt acl support = No
> 	acl map full control = No
> 
> I would also remove this line, as you have it set, any executable can
> be run, even if it isn't set as an executable:
> 
> 	acl allow execute always = Yes
> 
> If you have any concerns about removing these lines, I suggest you
> read 'man smb.conf', I think you will see why I suggest removing
the
> lines ;-)
I agree and will clean up asap. That server was set up and maintained by 
a former admin ... so far I tried to change only minor things to not 
break anything and keep the users happy.

But I absolutely see the need to clean up.

Am 10.11.18 um 10:40 schrieb Stefan G. Weichinger via samba:
> I agree and will clean up asap. That server was set up and maintained by 
> a former admin ... so far I tried to change only minor things to not 
> break anything and keep the users happy.
> 
> But I absolutely see the need to clean up.
I also rebuilt the package for samba in gentoo. They have a USE-flag 
"acl", it was and is enabled, I rebuilt the packages for acl-binaries
as
well ... assuming that samba depends on these ?

smb.conf cleaned up, I don't have access to any windows machines there 
and don't know if I could test acls via smbclient somehow? Anyway, 
weekend, tests on monday with their admin ;-)

by, thanks, Stefan