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

Patrick Goetz pgoetz at math.utexas.edu
Fri Nov 12 14:45:50 UTC 2021



On 11/9/21 12:44, Nick Couchman wrote:
> On Tue, Nov 9, 2021 at 12:49 PM Patrick Goetz via samba 
> <samba at lists.samba.org <mailto: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/ <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.
> 

Sorry to be a pest, but this still doesn't work the way I would expect 
it to, and I'm too OCD to let it go. I'm happy to use "force group" as 
Nick details below (this works, already tested), but the man page entry 
above bothers me.

So, updated details:


[share]
    comment = Share Directory
    path = /data/share
    guest ok = no
    browseable = yes
    writeable = yes
    create mask = 2770
    directory mask = 2770
    # force group = ea-staff
    follow symlinks = yes

Here are the linux permissions:


root at data2:/data# ls -ld share
drwxrws---+ 4 root ea-staff 4096 Nov 11 08:49 share
root at data2:/data# getfacl share
# file: share
# owner: root
# group: ea-staff
# flags: -s-
user::rwx
user:root:rwx
user:ea-staff:rwx
group::rwx
group:ea-staff:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:ea-staff:rwx
default:group::rwx
default:group:ea-staff:rwx
default:mask::rwx
default:other::---


When I look under security properties of the share folder in Windows I see:

   root: full control
   Creator Owner: full control
   Creator Group: full control
   ea-staff: full control

i.e. exactly what I'd expect to see (in particular, no inheritance issues)

However, when a user in the ea-staff group creates a file:

root at data2:/data/share# ls -l fifthpermtest.txt
-rwxrwx---+ 1 dheles domain users 7 Nov 11 08:46 fifthpermtest.txt


Domain Users just shows up with full control under the Windows security 
tab for the file as well.

Based on the smb.conf man page description I would expect this parameter:

   create mask = 2770

to force the group to ea-staff.  Folder creation goes the same way:

root at data2:/data/share# ls -ld Davids\ Stuff/
drwxrws---+ 2 dheles domain users 4096 Nov 11 05:33 'Davids Stuff/'
despite

   directory mask = 2770

What would be awesome is a Wiki page that details the logic Samba uses 
to set permissions.  I feel like I'm still missing something; i.e. if I 
set up a POSIX ACL under linux, it does show up instantly in the Windows 
security tab, so it seems like at least the Linux perms -> Windows perms 
mapping works well. I'm just not getting how/where Domain Users is 
showing up without invitation. Is this some kind of Windows idiosyncrasy?


> 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



More information about the samba mailing list