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

Stilez stilezy at
Fri Apr 6 17:42:32 UTC 2018

Thanks Andriy

I think we might differ on what "default expectations" are. My ezpextations 
for FreeBSD are based on the FreeBSD man pages - whatbelse should they be?  
But we can agree that only FreeBSD is being discussed (not any other OS nor 
ZFS or permissions norms for any other OS). And on **FreeBSD 11.x** surely 
the expectations a user should have for setuid and how it's handled are 
derived 100% from FreeBSD 11.x man pages, not some other "original" or 
"conventional" meaning that isn't FreeBSD 11.X. And the relevant man page 
says files+dirs, not just files. If the zfs man page originated on illumos 
then - like other files originating elsewhere - it really needs 
inconsistencies not matching **this** OS fixed within FreeBSD builds.

tl;dr - I don't think one can say "learn about this from the OS's man 
pages" if they are misleading **for this OS**, or as fallback say its based 
on some external or historical norm/meaning that the user should somehow 
know instead  :) That's a  bit much to hope for. The kind of user who knows 
that, probably doesn't need the man page for ZFS or chmod  anyway :)

I had looked at ACLs before asking. They don't work for this, your info 
looks wrong AFAIK. They only allow inheritance of permissions, not 
ownership. None of the ACL flags and nothing in setfacl man page, says 
anything about ownership inheritance. I'm using NFSv4 of it matters, but 
I'm guessing that's the default for ZFS based file hierarchies?

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?

Thanks again,


On 6 April 2018 3:01:31 pm Andriy Gapon <avg at> wrote:

> On 06/04/2018 16:12, Stilez Stilezy wrote:
>> Thanks Andriy,
>>     Please read in the manual what ZFS setuid property means.
>>     By the way, it's on by default, so you would typically turn it off if you don't
>>     want suid binaries.  And, of course, suiddir != setuid and ZFS does not support
>>     it, afaict.
>>     TLDR: yes, setuid works; no, it's not suiddir. 
>> I did look up the ZFS setuid property in the man pages. If there are there 
>> pages
>> I missed, can you point me to them (and sorry for not finding them!)
>>     *[man zfs]:*
>>          setuid=on | off
>>            Controls whether the set-UID bit is respected for the file system.
>>            [Does not say anything else, seems perfectly clear]
> Except that the original, conventional and default meaning for set-UID is for
> executable files.  Also, don't forget that this manual page originated on
> illumos (!= FreeBSD).
> E.g., see POSIX:
> S_ISUID	04000	Set-user-ID on execution.
> S_ISGID	02000	Set-group-ID on execution.
>>     *[man chmod]* - where it's documented what the set-UID bit does when set on
>>     a file system:
>>         4000 (the setuid bit).
>>           Directories with this bit set will force all files and sub-
>>           directories created in them to be owned by the directory
>>           owner and not by the uid of the creating process, if the
>>           underlying file system supports this feature...
> Right.  The last clause is very important.
>>           [Does **not** say that mount -o suiddir is/isn't required, or is/isn't
>>     a "blocker".
>>            Just says "see suiddir mounting option". But zfs man page has already
>>     said
>>            the bit **will** be respected. It's a bit conflicting.]
> Yes, ZFS respects the bit in the standard compliant sense.
> Not in a FreeBSD-specific optional extension sense.
>> Like I said, the man pages seem a bit conflicted. *[man zfs]* definitely 
>> says it
>> provides an option for the setuid bit to be respected for the file system - it
>> doesn't say "for files only" or any other limitation. It just says that setuid
>> will be "respected for the file system" if the flag is enabled on the dataset. 
>> *[man chmod]* describes what happens if setuid is "respected on a file system".
>> It's clear that this will force+inherit directory ownership "if the underlying
>> file system supports this feature". As [man zfs] already says set_UID will be
>> "respected", set-UID is clearly supported by ZFS.
>> As you can see, I did read the man pages carefully. That's why I asked help to
>> understand if it was documentation, implementation, or invocation, which 
>> was the
>> issue.
>> If the zfs setuid property _doesn't_ mean the same as normal enabling of the
>> setuid bit functionality, then the [man zfs] page is misleading. If it works
>> only for files but not for directories, it's also misleading.
> No, it is not misleading.
> You just have wrong default expectations :-)
> This wikipedia page seems to be surprisingly correct:
>> So I hope you can
>> see, I'm not asking because of failure to read the man pages. I really did 
>> read,
>> and followed them carefully, before asking.
>> So your answer was helpful (thank you!), even if I don't understand what info I
>> didn't read in the man pages. I have 2 quick points arising:
>>  1. I gather from your reply that even with this flag set, set-UID for ZFS based
>>     directories' ownership/inheritance is not "respected for the file system" -
>>     or not fully respected in the sense normally understood as in [man chmod]? 
>>     If that's the case then [man zfs] is incorrect - please can you confirm
>>     exactly what is this flag's functionality, since it's unclear?
> Just to repeat what I said above.  It is respected in the normally understood
> sense.  The FreeBSD extension (that has to be enabled via a special non-default
> kernel option and that works only for a small set of filesystems) is not 
> supported.
>>  2. Returning to the original issue, is there any way one can automatically
>>     force owner+owner inheritance, for data in a zfs dataset?
> This is 21st century.
> Access control lists.
>> Thank you for your help, even if not the ideal answer.
>> I hope these last couple of points are easy to clear up, and not annoying :)
> --
> Andriy Gapon

More information about the freebsd-fs mailing list