Does setuid=on work on ZFS datasets, or is the man page for zfs misleading?

Stilez Stilezy stilezy at
Wed Apr 11 11:32:58 UTC 2018

On 10 April 2018 at 06:45, Andriy Gapon <avg at> wrote:

> On 06/04/2018 20:42, Stilez wrote:
> > So the question stands - is there any working method to ensure files in
> a ZFS
> > dataset or contained dir have a predetermined owner? Including within
> ACLs if I
> > missed the right page?
> My assumption was that the ownership change was not an end goal and there
> was a
> wider context related to access management.
> In other words, why do you want to change file ownership unless you want to
> change the file's access rights...  In my opinion, Unix file ownership is
> a part
> of Unix file access model.

Good question. Four reasons come to mind:

1. I'm a comparative newcomer to FreeBSD security and related matters, and
don't have the skill/knowledge to make assumptions that an experienced
fbsd-er might make. My assumption is that whatever owner permissions/ACLs
are set at, and whatever exec rights exist, files are more vulnerable to
issues I leave open or mistakes I make, if they accidentally have a
privileged owner, compared to a non privileged one. A lot of work I do in
CLI is done with su-ing to a privileged account. The files don't need a
privileged owner, so why give them one, or expose them to having one?

2. Another reason is that some branches of the file system are accessed via
Samba, and if ACLs aren't correct, Windows tends to look at the owner as
the account able to fix it. If files accumulate different owners, that
could become a real pain to sort out as the file system is in the millions
of files.  This probably isn't so important because Samba allows owner
inheritance on any dir, but I'd like to rely on OS controls rather than
Samba controls.

3. An old principle of computing - if something isn't needed but adds
complication, don't do it. I don't need the files to have varied owners, so
varied owners becomes at best useless, at worst a pain at some
unforeseeable future time.

4. Finally of course, ACLs and ownership committed within short and long
term snapshots never can be changed or fixed. If any of these ever do give
rise to a problem, I won't be able to fix it short of an insane amount of
cloning/sending/rebuilding of the pool and every snapshot in it.

At present I'm currently tightening my "archived files" pool's permissions,
having dealt with most other basics. I'm starting from the top down - get
ownership right, then groups, then ACLs/permissions on owners/users/groups.

If FreeBSD can't do ownership inheritance, I have to think whether it's
actually a problem and if so what to do. Perhaps the simplest option is to
treat ownership as untrusted and give null ACLs (no rights at all) to the
owner;  instead just condition all access rights on user/group only. As far
as I understand, that should be as secure/effective, and will inherit.

So instead of forcing all files to be owned by (say) userX, and giving
userX some rights, I could acept that the owner is arbitrary, give the
owner no rights at all, create a user or group called "data_file_owner",
and give that user/group the access rights over the dataset root dir that I
would have given the owner. My understanding is that even on ZFS that setup
*can* be configured to forcibly inherit when files+dirs are created.

Would that angle work as I intend? Any issues/warnings for me, that I
should be aware of?


More information about the freebsd-fs mailing list