From owner-freebsd-fs@freebsd.org Fri Apr 6 17:42:32 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABD34F99752 for ; Fri, 6 Apr 2018 17:42:31 +0000 (UTC) (envelope-from stilezy@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E5D26B839; Fri, 6 Apr 2018 17:42:31 +0000 (UTC) (envelope-from stilezy@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id r82so4778247wme.0; Fri, 06 Apr 2018 10:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:date:message-id:in-reply-to:references:subject :mime-version:content-transfer-encoding; bh=+dnI7jtTBv1eE6L0TZI7N4cnz1MGal5UQwQMpBUKnpE=; b=K2py1jakeU/p1WXvu1HqBU0IOnDUJzZ4oBEr224er3sqJiBaVzD7o3StOK0Vr5kIsJ 3PVN4iCaWmwINNhw63ryuz+nVvYpM1ik4wtXHkbQ5xs/0ie5C1w9bSIFk+qDMKKsdQte gVH1OEbQfJw+pue+OCEXRyapED9+8t0rWuLXkG2VZE/XUFeQhkJQvklct4RnN7pnnvEN IIyWZhdMeNtQWXKyfW1o6kCnz/XAzf98bI2oSz2EqTpwEOVlGu4othu+bMMBp0rxhaTt CROxfTPcbD4OYpAtKH7t8aT+nFqeG/vGC10+naBnQxZ+74E+aoCvHbUBSLmPcQlSlmo+ iLYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:date:message-id:in-reply-to :references:subject:mime-version:content-transfer-encoding; bh=+dnI7jtTBv1eE6L0TZI7N4cnz1MGal5UQwQMpBUKnpE=; b=L6OVHdTTtlSwYgJyCc+yR4fqJr4I4d3kPF4xyE87/8kBwiV9ZvtBkdypCtJxntw6YU VCLF3j7TQJQRcQGKgsLBvWSIjmJlL306R9c7eQTt5lHt/JEbMIHa7jbgYERlCfmGmyZu 87zLB/JI4BaTq675M2cozBxN/CS9dxZSV5GqRA9DIA64abHkpM9l5CLkl37rRcWbXMzp YTSxhQQycxC2l6coeFhugfqGW3pVh77boP4mMHR1swGGLEm4D9fX40OcGyrb3KUxKSFa Vqc5JzdaEN7EuRackQJVg5/nuxUvA00YovuptNNEZ6OELTv9pUtLeOmXEHajkSkI7uHS CcmA== X-Gm-Message-State: ALQs6tBPgy8vD3Kt2AW1GWDplCsOPiZj34prkksB0IQ30PdS37PILLz/ hVLsrDeNCUoP9u2tUe/eQC5heH4r X-Google-Smtp-Source: AIpwx4+CVhFr+MRrxDp9bxncHt7no7UXeB0mOhL5a48MrHF0kCCuyuZ/HRc2Ka/oLe+vtE37xUKp9g== X-Received: by 10.28.16.18 with SMTP id 18mr13726597wmq.81.1523036549173; Fri, 06 Apr 2018 10:42:29 -0700 (PDT) Received: from [10.27.127.37] ([85.255.237.75]) by smtp.gmail.com with ESMTPSA id o88sm11456764wrb.44.2018.04.06.10.42.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 06 Apr 2018 10:42:28 -0700 (PDT) From: Stilez To: Andriy Gapon CC: "freebsd-fs" Date: Fri, 06 Apr 2018 18:42:26 +0100 Message-ID: <1629c0d63d0.2756.49a377fccbf53440a4b582c142a1ed88@gmail.com> In-Reply-To: <672e2c84-b906-4073-0206-7eb1720adc7e@FreeBSD.org> References: <7eba73db-3097-5c8a-eb2c-e3880fb5b501@FreeBSD.org> <672e2c84-b906-4073-0206-7eb1720adc7e@FreeBSD.org> Subject: Re: Does setuid=on work on ZFS datasets, or is the man page for zfs misleading? MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 17:42:32 -0000 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, Stilez On 6 April 2018 3:01:31 pm Andriy Gapon 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: > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html > 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: > https://en.wikipedia.org/wiki/Setuid > >> 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