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