[Samba] POSIX vs. Windows ACLs

Tue Nov 2 20:00:54 UTC 2021

Thanks, Jeremy; that was extremely informative.

So thinking out loud a bit. I've been looking at the AGDLP permissions 
design pattern espoused by many of the Windows AD people. At first I 
didn't think much of this until I heard someone point out that this is a 
way to avoid having to mess with your filesystem ACLs, which perked my 
interest, as I've spent what I would consider way too much time fine 
tuning ACLs on multi-user systems with beyond POSIX basic security 
requirements.

For the benefit of those not familiar with AGDLP, this stands for

   A  - Accounts
   G  - Global Security Groups
   DL - Domain Local Security Groups
   P  - Permissions (on resources)

The idea is that you set up permissions on, let's say, a directory 
resource for domain local groups, and then never touch them again.
You then grant/deny access to this folder by moving global groups in and 
out of the affiliated domain local groups.

So, it would work like this:

I have a directory called /data/experiments/

  - One group of users should have only read access
  - Another group should have read and write access

So I create 2 domain local security groups:  data-experiments-r, and 
data-experiments-rw and set the appropriate ACLs for these groups on the 
/data/experiments folder (using POSIX or Windows ACLs).

Right now bob, alice, ted, and jane should have rw access, and
bill, steve, sally, frieda, and nick should only have r access.

So I create a global group called G-pi-grad containing  bob, alice, ted, 
and jane, and another global group called G-students containing bill, 
steve, sally, frieda, and nick.

I then add G-pi-grads to data-experiments-rw and G-students to 
data-experiments-r.

Let's say right now nick is a student assistant, so shouldn't have write 
access to experiments. But he graduates and becomes a grad student with 
his own experiments to run.  No problem, I move nick from  G-students to 
G-pi-grads.

We start a collaboration with people from another lab, biff, boff, and 
boof. We'd like to give them read access to the experiments.  No 
problem, I create another global group called G-baff-lab containing 
biff, boff, and boof, and then add the G-baff-lab group to the 
data-experiments-r DL group.  When the collaboration is over, I remove 
G-baff-lab from data-experiments-r.

Notice I haven't touched the filesystem ACLs in all of this and don't 
plan to have to -- ever.

I think the original intention of this was to make it easier to share 
resources across domains, although the group types are horribly 
misnamed. "Global" groups are domain specific, and can only contain 
users/groups from a particular domain, while "Domain Local" groups can 
contain Global groups from any domain. Um, what?

For those in need of the finer granularity offered by Windows ACLs, one 
could envision creating DL groups for each required combination of ACLs, 
and perhaps even deny groups because, say, you want everyone in 100 
member G-labusers group to have write access to /important-stuff except 
for Jack, because he keeps getting drunk and accidentally deleting files 
in that folder, so jack would go in the data-experiments-d for deny 
group, which overrides G-labusers membership.

These *seems* like it would get unmanageable fast, but in real life how 
granular do most admins make these permissions anyway? I daresay that 
because many admins don't fully understand Windows ACLs, they keep it 
simple and could likely get by with what would be POSIX basic ACLs in 
the linux world. Anyone familiar with any small offices where everyone 
in the office has write access to every file in a giant shared 
filesystem?  I do. <:)

Any thoughts on this? My thought is this would allow me to stick to the 
POSIX ACLs I'm comfortable with and which afford easy ssh-fuse access to 
linux users at a remote location technically under an unaffiliated 
domain. To use Windows ACLs on linux, I would need to have each linux 
machine bound to the domain, and at the moment I'm not sure that's 
feasible. And since the filesystem ACLs never change, I wouldn't want 
Windows users messing with them anyway.

Based on what Jeremy said, I think it should be possible to convert from 
POSIX ACLs to Windows ACLs at a later date, if things change?

On 11/2/21 13:27, Jeremy Allison wrote:
> On Tue, Nov 02, 2021 at 04:49:01AM -0500, Patrick Goetz via samba wrote:
>>
>> Another question referring to a Samba domain member file server.
>>
>> The file system is ext4 on an Ubuntu 20.04.
>>
>> I would like to use Windows ACLs so my windows users can change 
>> permissions on directories/files, but we also use linux data 
>> processing systems, so the permissions (beyond POSIX basic) need to 
>> work there, too.
>>
>> I think this means I'm stuck using POSIX extended ACLs, with Windows 
>> users not being able to change permissions. Just want to make sure I 
>> understand all the possibilities:
> 
> No, Samba will map Windows permission in a best-effort case
> to POSIX ACLs. It can also keep a copy of the pristine Windows
> ACL in an EA associated with the file so access via Windows clients
> is mediated by the same Windows ACL algorithm used on a Windows
> server.
> 
>> Currently the linux systems access files through NFS mounts, so no 
>> hope of Windows ACLs working there, but if I were to bind the linux 
>> machines to the domain and do the mounts through SMB, would the linux 
>> systems respect the Windows ACL authorizations because permission is 
>> determined by the Samba file server?
> 
> Yes. Samba obeys the pristine Windows ACLs before delegating
> to the underlying filesystem - i.e. if a Windows ACL says deny,
> we deny. If a Windows ACL says "allow", we are still bound by
> the underlying POSIX ACL mapping on ext4 so it's possible you
> may get a missmatch and a "deny" when the Windows ACL would
> expect "allow". But this is failing safe, not failing open,
> which is what you want.
> 
>> Understood that I would lose the
>> ability to edit ACLs from linux, but the linux users are really 
>> Windows users working on a linux system because that's where the 
>> software is and they have no idea how to edit permissions there anyway.
> 
> Linux users can use the smbcacls binary to edit Windows ACLs
> on a remote server.
> 
>> Beyond this, if I'm working directly on the Samba file server, are 
>> there command line tools available for editing Windows ACLs, or is 
>> this sufficiently complicated that only a GUI will do?
> 
> smbcacls.
> 
>> The conjunction of linux and windows access control is a terrible 
>> mess, as already discussed, but the world doesn't stop moving as a 
>> result, so we will continue to cobble together bastardized 
>> arrangements that mostly work.  I'm at the Build a Frankenstein shop 
>> now...
> 
> "Puttin' on the Ritz !":
> 
> https://www.youtube.com/watch?v=ab7NyKw0VYQ
>>> This message is from an external sender. Learn more about why this <<
>>> matters at https://links.utexas.edu/rtyclf.                        <<
> 