From owner-freebsd-fs@freebsd.org Wed Apr 11 11:36:38 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 EE041F8C963 for ; Wed, 11 Apr 2018 11:36:37 +0000 (UTC) (envelope-from stilezy@gmail.com) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 76DF37C588; Wed, 11 Apr 2018 11:36:37 +0000 (UTC) (envelope-from stilezy@gmail.com) Received: by mail-vk0-x229.google.com with SMTP id r184so850799vke.11; Wed, 11 Apr 2018 04:36:37 -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=vTXo4oczS0cjm/mfhn3U/TZtY6O3y5T1TANvz8yiVwU=; b=Ja7DrBw4Z4MFCTTVKfM7oHGGBP+J/18BxTM2A5Eri422/oKSnmwkhJWtmDFY/kQ2+d EHNPhM5PpNTrFAx2B+5m2vz2Gryg1swxyyjbyhTD9J53lY0f32j0D0y3IZ57ph1VbKpJ Sbma945Ge0FHGrFUSvDa0Tuj7W7dIlztKLVbILkcrBzRoxbz3mQJsz3iPzTDMe2ez4IM Rz1ukD2tjyyrel/7kJr5wHYTTIENX7l3uw4A9sFMN/afeKRbBDGndfUUdlnst6mgbYkF ZypETtwVN0xClcng3PWugOb59sdDKKanVZDKeiisWUHRG10ubrioJRXbM3xLGQFAEy7V TQJA== 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=vTXo4oczS0cjm/mfhn3U/TZtY6O3y5T1TANvz8yiVwU=; b=LU1ZB91oFePpSaCn28hEc9e2G5HksCoT3yhhZCLxBROxLNTLnxvv1KWXfxOB3A7iea 8nuGE+Ssg0pdkEYYrFHr1sC6BeeRAcJzOszBxfkBlMX/ie0mD7j8cwfoyHOd2keyCt3+ VssgMmRrH8PPDJ4YQnqhqlZ9gIIBmjTcs2Z/8DCpAumH+v59viBbiGYd4bgkWubO8wtE UJ4Ocsumlvva1ws85Olrf5aJIThwgzWeulzzj+xqaSJzWhf09id1eT2w7BiuZmfwj8cy pCLoHjOX45uduoE0LCEcqeSE0FPZHZoKKYtw1vcMMlxDauMT+8TP7kwXLgT+cJaZa0y2 0I5g== X-Gm-Message-State: ALQs6tCciH9Ct0zXw7ER6rycFQgw4aQXrA71cS+F2DqRjOibUzkwrXFW bl0DWYHdYJX+Lk/diZuElIp6moohkaGZgA0UChr/Vw== X-Google-Smtp-Source: AIpwx48n6nY+pC9z5+4ORYwi2bb4S+2ivygnzO2qtqf6HijSb8KEKZZsx9sX1ySDxTdBmzMkg+tYaxYChaeGPzy0pGI= X-Received: by 10.31.61.216 with SMTP id k207mr2989447vka.125.1523446596877; Wed, 11 Apr 2018 04:36:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.219.148 with HTTP; Wed, 11 Apr 2018 04:36:06 -0700 (PDT) In-Reply-To: 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:36:06 +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:36:38 -0000 (Sorry, slight reword, my mistake, underlined correction: " 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 group called "data_file_owner", add my desired file+dir owner to the data_file_owner group, and give the data_file_owner 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." ) On 11 April 2018 at 12:32, Stilez Stilezy wrote: > > > 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 >