[Samba] permissions, and maybe a violation of the least surprise principle

[Patrick Goetz]

I'm down to the last step of my current re-implementation of Samba, 
namely getting the permissions to work right.

Here is the share section (+ some general) from my smb.conf file:


    winbind refresh tickets = Yes
    vfs objects = acl_xattr

[share]
    comment = Share Directory
    path = /data/share
    guest ok = no
    browseable = yes
    writeable = yes
    create mask = 0770
    directory mask = 0770
    # inherit permissions = yes
    follow symlinks = yes



Here are the filesystem permissions on the directory:

root at data2:/data# ls -ld share
drwxrws---+ 3 root ea-staff 4096 Nov  6 16:31 share

root at data2:/data# getfacl share
# file: share
# owner: root
# group: ea-staff
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:group:ea-staff:rwx
default:mask::rwx
default:other::---


Notice that the setgid bit is set, with group = (security group) ea-staff

So, I login on a Windows machine as a member of the ea-staff group, and 
save a document to the share:

root at data2:/data/share# ls -l top*
-rwxrwx---+ 1 dhales domain users 227 Nov  8 09:12 
top-secret_document_only_staff_should_see.rtf


Notice that the setgid bit on the parent folder was ignored, and the 
primary group assignment to the file is Domain Users.  Worse, anyone in 
Domain Users has access to write this file, although I suppose the lack 
of other  "x" permission on the parent folder might prevent access.

I think I read that if you are using Windows ACLs, then the Windows ACLs 
are checked and honored first; however this seems like a violation of 
the least surprise principle, since I'm getting user rights  elevations 
(namely Domain Users read/write access) that I don't want.

These Wiki pages talk about using POSIX and Windows ACLs respectively:

   https://wiki.samba.org/index.php/Setting_up_a_Share_Using_POSIX_ACLs
   https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs

  but I can't figure out how to tell the system I would prefer to base 
ACLs on POSIX rather than Windows ACLs.


Now, for the "it gets worse" category.  There is an awful lot of 
misinformation about configuring a Home share, perhaps because the 
Windows people seem to see this as something you use for backup only. 
The Home folder Wiki page also suggests that you can use GPO drive 
mapping for this rather than setting it in the user's Profile. Looking 
online I see Windows admins stating that one should *not* use GPO file 
sharing to configure the home directory and that only the user's Profile 
tab should be used for this.  In any case, Folder Redirection does not 
appear to work unless you set up a home directory under Profile.

Otherwise, using /home for this purpose appears to work fine and means 
the user will have immediate access to all their files when they ssh 
into the linux fileserver.  However:

[home]
    comment = Home Directories
    path = /data/home
    guest ok = no
    browseable = no
    writeable = yes
    create mask = 0700
    directory mask = 0700
    follow symlinks = yes

root at data2:/data# ls -ld home
drwxr-xr-x+ 8 root root 4096 Nov  6 08:27 home
root at data2:/data# getfacl home
# file: home
# owner: root
# group: root
user::rwx
group::r-x
group:domain\040admins:rwx	#effective:r-x
mask::r-x
other::r-x


/home is a bind mount to /data/home


The same user logs in on a W10 client and saves a file to his Documents 
folder:

root at data2:~# cd /home/dhales/Documents/
root at data2:/home/dhales/Documents# ls -l my*
-rwxrwx---+ 1 dhales domain users 222 Nov  8 09:25 my-super-secret-file.rtf


So looks like the create mask is being ignored as well?

I spend a lot of time adjusting permissions for users.  Most of them 
can't figure out how to do this themselves, and letting a user loose in 
the Windows ACL zoo seems like a recipe for disaster anyway.

Consequently I'd prefer to manage POSIX ACLs via the filesystem and ssh 
and then have the Windows ACL's approximated from that. Is there a way 
to do this?

It also seems to me that the filesystem permissions should *never* be 
bypassed under any circumstances.

Final question if anyone in the know has read this far. By default the 
Windows ACLs are stored in a TDB database on the fileserver's 
filesystem?  What happens to these permissions if I migrate the data 
(say, via rsync) to another server? Seems like all the Windows ACLs will 
be lost unless I transfer the relevant database as well.