Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 08 Apr 2017 23:51:58 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 218501] ZFS inherited filesystem ACLs don't update
Message-ID:  <bug-218501-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218501

            Bug ID: 218501
           Summary: ZFS inherited filesystem ACLs don't update
           Product: Base System
           Version: 11.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: josh@endries.org

Hello. I'm not sure this is specific to ZFS, but I suspect it is. I'm also =
not
sure if this is a bug or feature request, so I apologize for wasting anyone=
's
time. In any case, it doesn't work as I was expecting, so it *seems* like a=
 bug
to me...

It took me a long time to get ACLs on FreeBSD to work how I wanted, meaning
similar to how they work in Windows/NTFS--a surprisingly and embarrassingly
long time. It's almost impossible to set it up such that files actually inh=
erit
the ACLs of their parent(s), and it seems that it IS impossible to do this =
in a
maintainable/update-able fashion, which is very frustrating. I hope there i=
s a
method I just haven't found yet, but here I am nonetheless.

I have a ZFS file system with aclmode and aclinherit set to passthrough. The
passthrough value is supposed to cause any ACLs with the inherit flags to be
applied to any created child files. That is what the zfs manual page says, =
and
that seems to work. The problem is, if I later want to add a new ACL to
everything, there doesn't seem to be an easy way to do that, or it doesn't =
work
as I though it would.

What I need to do in that situation is something like:

1. Reconstruct the directory tree including any point at which the ACLs cha=
nge
for children. For example, create the root directory, set inheritable ACLs =
on
that, create root/sub, set ACLs specific to that directory and its children,
create root/sub/subsub, set those ACLs, etc.. Just the directories, essenti=
ally
creating a skeleton tree with all the inheritance pre-set.

2. Copy (without permissions) files from the original tree to the new tree.

3. Move the old tree and move the new tree to the old tree's location (to
reduce downtime).

Since I am technically creating files when I do this copy, it inherits the =
ACLs
as expected (I suppose). If, instead, I just use setfacl on, say, the root
directory, it happily adds the inheritable ACL on the root, but doesn't
propagate that change to any of the children. Creating new files that are
immediate children of the root will inherit the new inheritable ACL, but no
existing files will, no children beyond that first level will, and nothing =
I've
tried makes them change (e.g. touching, move to *-tmp name and back, I can't
remember what else at this point, been a lot of random attempts).

I need to use inheritance because I have too many files to set ACLs on them=
 all
individually--ZFS has some crazy small limit on total number of ACL entries=
 on
a filesystem. Inheritance somehow avoids this issue (maybe that's a bug). E=
ven
if it didn't, I wouldn't want to set individual ACLs on thousands of files =
when
we have inheritance, because it's a lot easier to maintain with a single ru=
le.

Ideally there would be a tool or an option to setfacl which applies inherit=
able
ACLs to children when adding/modifying (not individually, but "correctly").
Maybe this already exists and I'm just not aware of it, or if people have
methods better than copying, that would help.

I even switched to Linux at one point but it's even worse over there (witho=
ut
ZFS passthrough). I'd really rather not have to switch to NTFS; I like fbsd,
I've been using, supporting and advocating for it for almost 20 years now.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-218501-8>