From owner-freebsd-fs@freebsd.org Wed Apr 11 11:32:58 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 13B35F8C5D4 for ; Wed, 11 Apr 2018 11:32:58 +0000 (UTC) (envelope-from stilezy@gmail.com) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 9EFB07C413; Wed, 11 Apr 2018 11:32:57 +0000 (UTC) (envelope-from stilezy@gmail.com) Received: by mail-vk0-x22d.google.com with SMTP id n64so842359vkf.12; Wed, 11 Apr 2018 04:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Aylmx3Jmw1KQP71hYQLfZkhgLjYCLc8rCuANdSXqP1A=; b=kF2/pZZfoWmLH7CGlIFnI0hNnYL2977zUyHp1b9qBHQN/8KD1glktLMp/mXsE8YUfG PgiJNStnMEHpz2/G6HALreFAvH9W7WBAd5fFzG9GcPh91B6Z10EVVT7e+XpT4de7oEhM M+6b6ISJI9VjgUBp/gGvkszZFRnfHswmtNtBACL5KSi7Jt/UCBYDlA7mY9oxNopjO5ok FGF1n6fntVHSa/gzY1IMl2vb7q6JMzctKghRVkbMEmH1rEhE4DKpa7KY9p5IDtBNsHYi LRWHv+/o6+L4v6ivVl7dZEMskQiGgs288oT58SOyrSXlT9kNceeCf4JdjVT1FDWHtYEc yNkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Aylmx3Jmw1KQP71hYQLfZkhgLjYCLc8rCuANdSXqP1A=; b=tSOAu6g+119ODfQVf3X/26Z4XDr3w5PF4op3itLj4N2v0XWCXHocl71J/ePtd1eiil 3cFNw+Ij98v8wsPpJsun4dkApCqOhXauJldvXmqttktyv0rVLgQzft8L8Amc6KpcSXT2 0Cf1yap4bhGJLMhq3ezFKpuVMSpFTJGidoR3wDvxmBDMf/yjpRggggNrgVTN9uF353LH zZmslZspiDrjKZVBX1J4bep8RFtKdE5iBTKwRXveissmm4lvcwwrtWWB0iR53Dv1fVvs s+b/pi979THndyLQo0Hm7FA2xfMq/fO4cUNsbENDNx3cpgY5Tl5CZH4Qrx513A0Nuh8h PYSg== X-Gm-Message-State: ALQs6tAkKFJ48sz03ovtnWeDRmrWik0VrSythjRb0OpDdtyklclJ5/4X XLbyTWuqXlx68HWVXav3HFG9dbfXbsog/FCJhRA= X-Google-Smtp-Source: AIpwx49XY5/m8tRWLdfOIusEncic9+x4YfVOhdkmJSt8aILjFz5IuWHhTHF0IYctGUZalwY9zl/fR2bRoZY43USJRmk= X-Received: by 10.31.197.197 with SMTP id v188mr3072075vkf.18.1523446376955; Wed, 11 Apr 2018 04:32:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.219.148 with HTTP; Wed, 11 Apr 2018 04:32:26 -0700 (PDT) In-Reply-To: <26e3c3b5-9baf-5499-0e12-81486cc8c839@FreeBSD.org> References: <7eba73db-3097-5c8a-eb2c-e3880fb5b501@FreeBSD.org> <672e2c84-b906-4073-0206-7eb1720adc7e@FreeBSD.org> <1629c0d63d0.2756.49a377fccbf53440a4b582c142a1ed88@gmail.com> <26e3c3b5-9baf-5499-0e12-81486cc8c839@FreeBSD.org> From: Stilez Stilezy Date: Wed, 11 Apr 2018 12:32:26 +0100 Message-ID: Subject: Re: Does setuid=on work on ZFS datasets, or is the man page for zfs misleading? To: Andriy Gapon Cc: 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: Wed, 11 Apr 2018 11:32:58 -0000 On 10 April 2018 at 06:45, Andriy Gapon 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? Stilez