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

OK, I think I'm starting to absorb the idiomatic usage of permissions in 
Windows. The group always just defaults to Domain Users and then you 
control access through filesystem permissions.

However, (see below)

On 11/8/21 16:50, L.P.H. van Belle via samba wrote:
> 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.
> 

I'm not seeing what the setuid/setgid bits are doing for Windows 
permissions.  In particular, on linux at least the setuid bit is just 
ignored when set on a directory (see the link just above).

I can see setting the setgid bit, as this means group permissions behave 
property when set from linux, but this doesn't seem to do anything on 
Windows permissions.  And when you save a file to the folder, the 
default group set on the file is Domain Users.

And, as far as I can tell Creator Owner and Creator Group are set on 
every folder regardless of whether or not the setuid/setgid is set.

> 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
>>
>>
> 
>

On Tue, Nov 9, 2021 at 12:49 PM Patrick Goetz via samba <
samba at lists.samba.org> wrote:
> OK, I think I'm starting to absorb the idiomatic usage of permissions
in
> Windows. The group always just defaults to Domain Users and then you
> control access through filesystem permissions.
>
> However, (see below)
>
> On 11/8/21 16:50, L.P.H. van Belle via samba wrote:
> > 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.
> >
>
>
> I'm not seeing what the setuid/setgid bits are doing for Windows
> permissions.  In particular, on linux at least the setuid bit is just
> ignored when set on a directory (see the link just above).
>
> I can see setting the setgid bit, as this means group permissions behave
> property when set from linux, but this doesn't seem to do anything on
> Windows permissions.  And when you save a file to the folder, the
> default group set on the file is Domain Users.
>
> And, as far as I can tell Creator Owner and Creator Group are set on
> every folder regardless of whether or not the setuid/setgid is set.
>
>
A couple of notes, here - forgive me if I'm headed off in a direction that
doesn't make sense or that you've already covered. In your original
post,
you posted the following share configuration:

 [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

The manual page for smb.conf says of "create mask" (directory mask is
the
same):

           When a file is created, the necessary permissions are calculated
           according to the mapping from DOS modes to UNIX permissions, and
           the resulting UNIX mode is then bit-wise 'AND'ed with this
           parameter. This parameter may be thought of as a bit-wise MASK
for
           the UNIX modes of a file. Any bit not set here will be removed
from
           the modes set on a file when it is created.

Since you've omitted the setuid, setgid, and other bits, here (the
"0" on
the left-hand side of the mask), those bits will be removed when
Samba writes files, which means your files/directories will not retain
their setuid/setgid status. From the "chmod" man page:

       A numeric mode is from one to  four  octal  digits  (0-7),  derived
 by
       adding up the bits with values 4, 2, and 1.  Omitted digits are
assumed
       to be leading zeros.  The first digit selects the set user ID  (4)
 and
       set group ID (2) and restricted deletion or sticky (1) attributes.
The
       second digit selects permissions for the user who owns the  file:
 read
       (4),  write  (2),  and  execute  (1); the third selects permissions
for
       other users in the file's group, with the same values; and  the
 fourth
       for other users not in the file's group, with the same values.

So, if you wanted to allow Samba to retain the setuid and setgid bits on
both files and directories, you'd need to set:

create mask = 6770
directory mask = 6770

If you only wanted these kept on directories, keep "create mask" as
0770
and only alter "directory mask". If you only want setgid, then
you'd set:

create mask = 2770
directory mask = 2770

etc. Also, if you're still looking to have files owned by a group other
than domain users, you could set the "force group" option to
something:

force group = +"DOMAIN\Special Group"

The + in front causes Samba to only force that group if the user is already
a member of that group.

-Nick

On Tue, 2021-11-09 at 08:19 -0600, Patrick Goetz via samba
wrote:
> OK, I think I'm starting to absorb the idiomatic usage of permissions
> in 
> Windows. The group always just defaults to Domain Users and then you 
> control access through filesystem permissions.
> 
> However, (see below)
> 
> On 11/8/21 16:50, L.P.H. van Belle via samba wrote:
> > 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.
> > 
> 
> I'm not seeing what the setuid/setgid bits are doing for Windows 
> permissions.  In particular, on linux at least the setuid bit is
> just 
> ignored when set on a directory (see the link just above).
> 
> I can see setting the setgid bit, as this means group permissions
> behave 
> property when set from linux, but this doesn't seem to do anything
> on 
> Windows permissions.  And when you save a file to the folder, the 
> default group set on the file is Domain Users.
> 
> And, as far as I can tell Creator Owner and Creator Group are set on 
> every folder regardless of whether or not the setuid/setgid is set.
Try reading the smb.conf manpage, specifically the 'inherit
permissions' section.

Rowland