[Samba] permissions, and maybe a violation of the least surprise principle
Patrick Goetz
pgoetz at math.utexas.edu
Mon Nov 8 16:32:54 UTC 2021
On 11/8/21 10:14, Nick Couchman wrote:
> On Mon, Nov 8, 2021 at 10:54 AM Patrick Goetz via samba
> <samba at lists.samba.org <mailto: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_POSIX_ACLs>
> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_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.
>
Then I'm confused about why my setgid bit is being ignored, or why
'create mask = 0700' is being ignored in the Home folder share.
Samba is adding POSIX extended ACLs for "Domain Users" to all saved files:
root at data2:/home/dhales/Documents# getfacl my-super-secret-file.rtf
# file: my-super-secret-file.rtf
# owner: dhales
# group: domain\040users
user::rwx
group::---
group:NT\040Authority\\system:rwx
group:domain\040users:---
group:dhales:rwx
mask::rwx
other::---
Although it looks like:
group::---
group:NT\040Authority\\system:rwx
group:domain\040users:---
Domain Users doesn't have any rights from the POSIX extended ACL side.
However, the POSIX basic filesystem rights assignment is what is
problematic here:
root at data2:/home/dhales/Documents# ls -l my*
-rwxrwx---+ 1 dhales domain users 222 Nov 8 09:25 my-super-secret-file.rtf
Looks to me like any domain user can end up not only reading but being
able to write to this file, at least if logged in on the linux host.
> -Nick
More information about the samba
mailing list