From owner-freebsd-arch@freebsd.org Thu Dec 3 09:58:34 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7775DA3E2D1 for ; Thu, 3 Dec 2015 09:58:34 +0000 (UTC) (envelope-from uebayasi@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 468321318; Thu, 3 Dec 2015 09:58:34 +0000 (UTC) (envelope-from uebayasi@gmail.com) Received: by ioir85 with SMTP id r85so75546245ioi.1; Thu, 03 Dec 2015 01:58:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=APiD3O6uTQKr5fN7F5fK4BKYx84f5e5Cip3+HcVNy8A=; b=qNxvsfy3+ip8zKGVEJY+ZgE/ZlvKS1DAeLLXRnVwtyKPMNBPhQis57SV1NLVlwOaRq pc1ko+bODSPYGOcoEa/idrooTeDqPW5Kxpviw9TquSaAtyAjPeDsEs1IDuZKLGSyj701 1OP/vJLfreZ5mYpVC+eZCriohH7OYRBTx7fpbQDFGSAYPHNjt+5mO1EDYnL+xrhK6SVI o1P5EXRBTHPixtk+3mH/asHrFOkC2hryn11TN4UYK3VJ/QPebg1TbWiPxYzI42OyrKZ4 5n/u7u5a3L1aa0vRtGiyGlgtC+FZzroJIsBMBHadlkBXs1Zxe09pRuTiTIWemoq+wN7i a5xw== MIME-Version: 1.0 X-Received: by 10.107.132.11 with SMTP id g11mr9502752iod.56.1449136713017; Thu, 03 Dec 2015 01:58:33 -0800 (PST) Received: by 10.64.18.80 with HTTP; Thu, 3 Dec 2015 01:58:32 -0800 (PST) In-Reply-To: <71D3DCA2-B336-4849-88E3-8412F8A93324@kientzle.com> References: <0A51B6D4-9EDD-4EFF-876F-C6B515DBB4F3@kientzle.com> <71D3DCA2-B336-4849-88E3-8412F8A93324@kientzle.com> Date: Thu, 3 Dec 2015 18:58:32 +0900 Message-ID: Subject: Re: mtree "language" enhancements From: Masao Uebayashi To: Tim Kientzle Cc: Warner Losh , "Simon J. Gerraty" , Michal Ratajsky , Brooks Davis , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 09:58:34 -0000 On Tue, Dec 1, 2015 at 11:31 AM, Tim Kientzle wrote: > >> On Nov 29, 2015, at 9:49 PM, Warner Losh wrote: >> >> On Sun, Nov 29, 2015 at 9:28 PM, Tim Kientzle wrote: >> >>> >>>> On Nov 29, 2015, at 2:49 PM, Tim Kientzle wrote: >>>> >>>> Simon also asked: >>>>> Indeed I'd really like the ability to provide default uid/gid >>>>> for the case that a uname/gname cannot be looked up. >>>> >>>> I think 'tar' got this right: If uname and uid are both specified, th= en >>> look up uname and if that fails, use the specified uid. Ditto for >>> gname/gid. In particular, this lets a single specification be used to >>> rebuild a tree on another system with different UIDs or on a system tha= t >>> does not (yet) have a full password file. An option could be provided = for >>> the (rare) case that someone really wants to prefer UIDs to unames. >>> >>> On further reflection, preferring UIDs to unames would actually be pret= ty >>> common here. >>> >>> In particular, NanoBSD (and Crochet and other similar tools) should pre= fer >>> the UID when building images instead of looking up unames against the b= uild >>> host's password file. >> >> >> I've implemented what we've talked about, except this. When doing the >> makefs, we should use the /etc/master_password that's inside the image i= n >> preference to either of these alternatives. That's the most correct thin= g >> to do: use as much of the data as you can, as late as you can. >> >> The thing I'm struggling with now is why would both be present? Would th= at >> indicate an error? Or someone changing the defaults? And if they are >> changing the defaults, why use a uid in preference to a uname? Is this t= o >> avoid contamination? To set something not in the password file, or just >> comfort level of the user? FreeBSD will write unames for install*. >> >> So I'm left thinking that maybe the rule should be 'last one wins' at le= ast >> for the use case where we use the target's /etc/master_password. That's >> what I've actually implemented. > > There are two key cases that drove this design for tar: > > 1. Handling user info that is not (yet) in the target password file. In= practice, images get built up in different orders: I might add a bunch of= new files owned by a new user before some other process gets a chance to a= dd the user. When you say "image", you surely mean "file-system image". File-system image contains on-disk data (inode), which contains UID/GID instead of symbolic ones (uname/gname). When you decide to create an image, you have a whole tree (directories/files) that ends up in a generated file-system image. Which means that when you create an image, you must know all the files and UIDs/GIDs put there. If not, what you are creating should not be an image. If you don't know UIDs/GIDs, can't you just create a tar archive, and extract it when you really create an image later? I don't really want mtree(1) unnecessarily smart so it makes unnecessary decisions. I want it to be simple and deterministic. > 2. Restoring info when the target has different user numbering than the = host. (Or when the user isn=E2=80=99t in the host password file at all.) > > For #1, you need the UID since the uname can=E2=80=99t be looked up anywh= ere. For #2, you must have the uname since the UID would be wrong. An ima= ge that can work in either scenario needs to have both. > > For NanoBSD, you may be able to enforce that users are always present in = the target password file before any data owned by those users is added to t= he image. So it may be reasonable to just rely on uname everywhere for now= . > > Tim > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"