[Samba] Using filegroup for access control within a share

[Trond Hasle Amundsen]

On Wed, 2016-02-10 at 09:57 +0000, Rowland penny wrote:
> On 10/02/16 09:41, Trond Hasle Amundsen wrote:
> > On Wed, 2016-02-10 at 09:20 +0000, Rowland penny wrote:
> >> On 10/02/16 07:44, Trond Hasle Amundsen wrote:
> >>> On Tue, 2016-02-09 at 15:17 -0800, Jeremy Allison wrote:
> >>>> On Mon, Feb 08, 2016 at 01:54:33PM +0100, Trond Hasle Amundsen wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I have an issue with using a UNIX filegroup for access control within a
> >>>>> share. The situation is like this:
> >>>>>
> >>>>> Given a share "test" which exports "/test" to a NIS netgroup "foo", I
> >>>>> want to limit access to the directory "/test/restricted" to a specific
> >>>>> filegroup "bar". All members of the filegroup "bar" are also members of
> >>>>> the netgroup "foo".
> >>>>>
> >>>>> This works fine with Samba 3.x, but not with Samba 4.x. When setting
> >>>>> owner/group to root/bar on "/test/restricted" and mode=770, access is
> >>>>> denied for all users.
> >>>>>
> >>>>> What can I do to make this work with Samba 4.x? Or is this simply not
> >>>>> possible anymore?
> >>>> More details and smb.conf on exactly how you've set this up please !
> >>> Thanks Jeremy, the (slightly sanitized) smb.conf is below. Let me know
> >>> if more information is needed, or if there is something you'd like me to
> >>> try.
> >>>
> >>> [global]
> >>>           auto services = homes
> >>>           load printers = yes
> >>>           print command = /usr/bin/ppr -r -P%p -J@%m -Xprint_errors=false
> >>> -u%u@%M -Xsmbclient=true -Xusepstitle=true %s
> >>>           printing = bsd
> >>>           lpq command = /usr/bin/ppq -P%p
> >>>           lpq cache time = 30
> >>>           socket options = SO_KEEPALIVE TCP_NODELAY
> >>>           deadtime = 60
> >>>           unix charset = UTF8
> >>>           unix extensions = no
> >>>           wide links = yes
> >>>           follow symlinks = yes
> >>>           max protocol = SMB3
> >>>           security = ads
> >>>           client ntlmv2 auth = yes
> >>>           lanman auth = no
> >>>           ntlm auth = no
> >>>           server schannel = yes
> >>>           client signing = auto
> >>>           password server = *
> >>>           realm = EXAMPLE.COM
> >>>           workgroup = EXAMPLE
> >>>           disable netbios = yes
> >>>           hostname lookups = yes
> >>>           syslog = 0
> >>>           time server = yes
> >>>           domain logons = no
> >>>
> >>> [homes]
> >>>           comment = Home
> >>>           veto files = /.rsrc/
> >>>           delete veto files = yes
> >>>           nt acl support = no
> >>>           inherit permissions = yes
> >>>           guest ok = no
> >>>           invalid users = root
> >>>           browsable = no
> >>>           read only = no
> >>>           strict locking = no
> >>>
> >>> [test]
> >>>           path = /test
> >>>           create mode = 0774
> >>>           directory mode = 0775
> >>>           browseable = yes
> >>>           public = no
> >>>           guest ok = no
> >>>           read only = no
> >>>           invalid users = root
> >>>           valid users = @foo
> >>>           veto files = /.??*/
> >>>
> >>>
> >>> The directory /test contains:
> >>>
> >>> -rwxrwxr-x. 1 root foo     0 Dec  9 16:26 file1.txt
> >>> -rwxrwxr-x. 1 root foo     0 Dec  9 16:26 file2.txt
> >>> drwxrwx---. 2 root bar    36 Dec  9 16:32 restricted
> >>>
> >>> The group "foo" is both filegroup and netgroup, containing the same
> >>> members. Samba version used is 4.2.3 (rhel7.2).
> >> Are you using sssd or nlscd instead of winbind ?
> > SSSD is running, configured to use an OpenLDAP server (i.e. not AD) as
> > id and auth provider. We're not using nlscd. AD does not have the UNIX
> > extension (or whatever it's called), so UIDs and GIDs will differ
> > between AD and OpenLDAP/SSSD. Samba is the only service that uses AD.
> 
> If sssd is running and you are *not* using winbind for auth, then Samba 
> is probably not your problem.
> At the moment I think that Samba knows nothing about your groups in 
> OpenLDAP.

Perhaps.. it depends on how Samba gets group info. If it uses the
standard glibc functions it shouldn't be a problem. If it asks AD
directly than you're right. However, access control using netgroups
and/or filegroups in smb.conf works fine, and these groups only exist in
OpenLDAP/SSSD. What doesn't work is additional access control using
filegroups directly in the filesystem as described above.

I still can't figure out why this works with 3.x and not with 4.x. The
smb.conf, SSSD config etc. is identical. Has something changed wrt. how
Samba uses the filesystem?

Regards,
-- 
Trond H. Amundsen <t.h.amundsen at usit.uio.no>
Center for Information Technology Services, University of Oslo