samba - Nov 2021 - permissions, and maybe a violation of the least surprise principle

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.

On Mon, Nov 8, 2021 at 10:54 AM Patrick Goetz via samba <
samba at lists.samba.org> wrote:
> 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.
>
>
You might try the "force group" option in smb.conf - there's an
option that
you can use with that, I believe pre-pending the group name with a
"+",
that will force the group only if the user is a member of that group.

> 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.
>
>
In those two pages, there are two different methods of ACLs that are
mentioned:
* POSIX ACLs, which use either basic POSIX permissions, or extended POSIX
ACLs (getfacl and setfacl) to process permissions. The permissions that you
see on the Windows side are just a best-effort mapping of Windows
permissions to POSIX permissions - there is no additional "storage" of
Windows permissions beyond what you see on the filesystem.
* Using the acl_xattr VFS module to store the extended Windows ACLs in an
extended attribute on the filesystem. This has the advantage of supporting
more complete and specific Windows ACLs, but at the cost that you're not
going to be able to "see" those permissions on the UNIX filesystem.
Unless
you set the option to ignore system permissions, Samba still tries to map
through the underlying ACL as best as possible (full control is rwx, modify
is w, read is r, execute is x, etc), so that there's some level of mapping
between the Windows and Linux permissions.

>
> 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.
>
>
No, this is not the default case. In order to actually enable storing
permissions in a TDB module, you'd need to enable the VFS module(s) that
support that - there's an "acl_tdb" module and a
"xattr_tdb" module that
enable ACL and Extended Attribute support in TDBs, respectively. Otherwise
the permissions are just mapped through from POSIX permissions as best as
possible.

-Nick

On Mon, Nov 08, 2021 at 09:38:18AM -0600, Patrick Goetz via samba
wrote:
>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?
No, that's not true. The Windows ACLs are stored by default
in EA's attached to the file.
> 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.
So long as rsync transfers EA's then all will work.

On Mon, Nov 08, 2021 at 09:38:18AM -0600, Patrick Goetz via samba
wrote:
>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
Check out the smb.conf parameters:

inherit acls
inherit owner
inherit permissions

Note that when you load "vfs objects = acl_xattr"
in order to make POSIX ACLs work as expected, the
module hard-codes the following parameters:

        /* Ensure we have the parameters correct if we're
          * using this module. */
         DEBUG(2,("connect_acl_xattr: setting 'inherit acls = true'
"
                 "'dos filemode = true' and "
                 "'force unknown acl user = true' for service
%s\n",
                 service ));

         lp_do_parameter(SNUM(handle->conn), "inherit acls",
"true");
         lp_do_parameter(SNUM(handle->conn), "dos filemode",
"true");
         lp_do_parameter(SNUM(handle->conn), "force unknown acl
user", "true");

In addition, you can set the parameter "acl_xattr:ignore system acls"
which if set to true will cause smbd to only look at the Windows
permission on a file, not the POSIX ones. This is used on "appliance"
devices where the only access to the filesystem is via smbd.

Setting this also changes:

		create_mask = lp_create_mask(SNUM(handle->conn))|= 0666;

                 lp_do_parameter(SNUM(handle->conn), "directory
mask", "0777");
                 lp_do_parameter(SNUM(handle->conn), "map archive",
"no");
                 lp_do_parameter(SNUM(handle->conn), "map hidden",
"no");
                 lp_do_parameter(SNUM(handle->conn), "map
readonly", "no");
                 lp_do_parameter(SNUM(handle->conn), "map system",
"no");
                 lp_do_parameter(SNUM(handle->conn), "store dos
attributes",

This is a complex topic as what people want from ACLs in smbd
varies enourmously, and we are trying to (a) keep backwards compatibility
as far as possible and (b) allow people to get as close to Windows ACLs
as possible and (c) give the flexibility for people to work with
Windows/POSIX/NFSv4
ACL models.

It's not easy :-).

I'll add my view on it. 

Windows can only hold 1 primary group for a user, which is by "Domain
Users".
So,yes, every file holds the "domain users" by default. Lets say GID
10000 is assigned.

By example. 
We have 2 users, bugger and bogger. 
Bugger is member of "domain users" (GID 10000) and SomeUseless group.
(GID 10001)
Bogger is member of "domain users" (GID 10000) and Staff group. (GID
10002)
>From a windows machine, default rights are set as you see in you output.
Which is all correct as far is see. 

Now, let remove the windows thoughts and just use POSIX. 
You change the default group in windows for both users to its group with GID.

Bogger places a file in the SomeUseless group, so bugger can open it. 
But the file owner now is bogger:staff, bugger isnt a member, 
so to bad he cant open/change it, even if its in the right folder.

This is why, i use in a  "linux with mixed windows" rights setup the
windows defaults

So, all "file rights" are "domain users" as group and every
member kan open/change it.
The fixes the above rights problem. 

On the "folder part". 
The acl is obeyed from windows and linux users cant enter it.
You use a group as security group to allow access only. 

Only one important part, or you need to change rights later on. 
Set the UID/GIDS first thing in the objectes, before you create folders, or the
GID doesnt show/is set.
Still need to look better into that, only so little time currently. 

Use from windows to posix are key "Creator Owner" and "Creator
Group" (mainly creator group)

Windows		: Posix
( Creator owner ) : 1770 (through sticky bit) ( normaly chmod 4770)
( creator group ) : chmod 2770
( creator owner and group ) : chmod 3770

https://chmodcommand.com/ has a nice explantion on the i at sticky bit and
SetGid.

And you can use getacl and setacl to copy right from windows to linux if you
like command prompt.

I hope this helped a bit. 



Greetz, 

Louis



> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Patrick Goetz via samba
> Verzonden: maandag 8 november 2021 16:38
> Aan: Samba listserv
> Onderwerp: [Samba] permissions, and maybe a violation of the 
> least surprise principle
> 
> 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.
> 
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
> 
>