From owner-freebsd-fs@freebsd.org Thu Apr 5 15:53:41 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 D1DFFF8F3F6 for ; Thu, 5 Apr 2018 15:53:40 +0000 (UTC) (envelope-from stilezy@gmail.com) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 6C8FA83330 for ; Thu, 5 Apr 2018 15:53:40 +0000 (UTC) (envelope-from stilezy@gmail.com) Received: by mail-ua0-x22a.google.com with SMTP id q38so15759441uad.5 for ; Thu, 05 Apr 2018 08:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=n5NRFoJbIWqkLUfb2oXtITcIPwJorW3RI9DZpGyH6JU=; b=nG8ZzLQqQoamPA4QX9fTxyVRHtdES4TGLwbVYq6ANI3F4XrnWHyrJ1ZKBQe19WRWvn 83imqh3m9IWc0r+8hqSvvAcuA6FrYkWC9ZhJZnW3zpu5jMZ+DulBdpoTL8HZYM+eausO vhIvkU2tBI38Nrxg3J50L4EgNXYxXc2Y5HT3NwjKTsKVw4o7tLcO7+AAggp1JKfCONBd k8Wze+Yzb1O4M2G9K15r3DgP5Hsvo4ZVrJ7sLUnrjeNqrZVJFKETmn5REfrr+zwD7ocj HvJi5MlN/pkJbNG6om04J2UB0zS7x6ZhTVXR8CleOa/cd+mfS2daH5dhSdM8tocoGDUf A6dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n5NRFoJbIWqkLUfb2oXtITcIPwJorW3RI9DZpGyH6JU=; b=Y652PZaWdbseoqwj1wCJzIckq4clQzJs2uMJXNt92aGZR3RG7AP6MblDqAGCYn3yrv e91n1Y+ErQURTCz17IaSO3stDwrnlAWTQrBZYDMFipIGKnEU7X+6nYSgGWaXEr4KjHF+ stmX5AouXsI/Wb/JB36VEcl5mRndlMP+PTwlRsklPOVREAvuMwYKcW8XevV9Y41BkWzG izwFT7T9F0Im19zFuDfFu6C6ndFgerrIaJDob5ahkgg0F5Hrb32L3X1AXkdUH0h6q2mT 6isSkE8mvS+wmK1L/uNzkFKuJr5+iaiR6g9GLe95Lfprx8V2EnAcJKM+ajrlbw6ATNP0 KETw== X-Gm-Message-State: ALQs6tBEcaw7ejHRONGb3NyBf0F3rwXVAqhKl9Zuw9qXbdmedpYe5Tw/ C0IwaWP7aUmpQGwf7ppwCDwkdzIo3eArtfDK8iN/LQ== X-Google-Smtp-Source: AIpwx48CVYvWZwJhLhkQ6UcYT/ucMyd+/dAYfuqrKkBTjLB19hln8+4ehZhEd8k3ytg4r8yTnYBCktmugNXCaesPBKA= X-Received: by 10.176.48.169 with SMTP id b9mr14473091uam.55.1522943619859; Thu, 05 Apr 2018 08:53:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.219.148 with HTTP; Thu, 5 Apr 2018 08:53:09 -0700 (PDT) From: Stilez Stilezy Date: Thu, 5 Apr 2018 16:53:09 +0100 Message-ID: Subject: Does setuid=on work on ZFS datasets, or is the man page for zfs misleading? To: freebsd-fs Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Thu, 05 Apr 2018 15:53:41 -0000 I'm trying to use the setuid property in ZFS. The man pages are a bit conflicted but overall man zfs seems most specific and implies the property is valid (man zfs says use setuid=on and it'll work, man mount says use -o suiddir but won't work except on UFS). It seems that man zfs is more specific/authoritative but I can't be sure. I'm starting to wonder if the page is wrong/misleading, and setuid isn't working/not implemented on datasets, despite the apparent meaning of man zfs. Here's an easily reproduced test case: # zfs create Test_pool/test # zfs list | grep test Test_pool/test 88K 446G 88K /mnt/Test_pool/test # zfs set setuid=on Test_pool/test # zfs get all Test_pool/test | grep setuid Test_pool/test setuid on local # mount | grep test Test_pool/test on /mnt/Test_pool/test (zfs, local, noatime, nfsv4acls) # umount Test_pool/test # mount -t zfs -o local,noatime,nfsv4acls,suiddir Test_pool/test /mnt/Test_pool/test # mount | grep test Test_pool/test on /mnt/Test_pool/test (zfs, local, noatime, suiddir, nfsv4acls) # chown www /mnt/Test_pool/test # chmod 4770 /mnt/Test_pool/test/ # ls -lt /mnt/Test_pool | grep test drwsrwx--- 2 www wheel 2 2018-04-05 16:11:48 test/ # ls -lt /mnt/Test_pool/test total 0 # mkdir /mnt/Test_pool/test/dir_created_as_root # touch /mnt/Test_pool/test/file_created_as_root # ls -al /mnt/Test_pool/test total 2 drwsrwx--- 3 www wheel 4 2018-04-05 16:19:17 ./ drwxrwxr-x+ 5 root wheel 6 2018-04-05 16:11:49 ../ drwxr-xr-x 2 root wheel 2 2018-04-05 16:18:33 dir_created_as_root/ -rw-r--r-- 1 root wheel 0 2018-04-05 16:19:17 file_created_as_root As far as I can see, everything's done that's needed. - Clean newly created dataset - setuid property set and checked - dataset mounted with suiddir option on - dataset given a different owner than my current invoked account, and setuid bit set - dataset properties, mount options, setuid bit, owner, etc all checked and seem correct - as root, created a new dir and file immediately within the dir - ..... but neither of them pick up the containing dir's actual owner and the dir doesn't pick up the setuid bit. Unless man zfs is misleading, setuid=on should work. (The exception is if it should say that it does work - but only for ZVOLs not datasets, which isn't what's said) What's going on? Or is this not implemented in ZFS and the man page not as clear as needed? If it *can't* be done within a normal ZFS dataset and the man page needs updating to be clearer, is there any "second best" workaround/fix to automatically get the right owner for that dataset's newly created files/dirs? For info, the platform is 11.1-REL on amd64. The files in the dataset could be created/modified/deleted by a number of users, hence why I want to mandate a fixed owner. I also don't want to create this directory as UFS-within-ZVOL, but to use a normal ZFS dataset. Thanks for any technical insight into this Stilez