From owner-freebsd-arch@freebsd.org Tue Dec 1 02:30:07 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 B5876A3DE9A for ; Tue, 1 Dec 2015 02:30:07 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 7C5861FEE for ; Tue, 1 Dec 2015 02:30:07 +0000 (UTC) (envelope-from tim@kientzle.com) Received: by pacej9 with SMTP id ej9so204669889pac.2 for ; Mon, 30 Nov 2015 18:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kientzle-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IzS1S5dFvPT1tBl+p31CcXO+Kxa2hlBdlZZowkhj77w=; b=w81m4xUuE5+5WyIQKI1g4OylOtqXE2mSwWmIQHjx0PqGJG16LRmHZmGj/a7kpMWrWH fVyRt9Rmr6ForrRGANyfPrxbWU2sQkUMYGn8+mm2w/FqhGMYmX3QYgRD5C0Q44WtDtrV ikM5M/DsS3rJVOkjRpKJEyDoDJmXa7AWtnsvKo44jSiC1q54CDr1ginUXL9S0Cv2AsZR wttL+gYzv7G4d68aONwdMTEdSyO8+IKef/asS6JhiVLGlGF1Cc3VV7aNuEd7Pl/WeGiU DcnSk1rHJLYnDffuNXA8FpnD/sHg4UUEqhbV/SerxX5813ha3xnHDUJIz1bwz0P0VlKn kN+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IzS1S5dFvPT1tBl+p31CcXO+Kxa2hlBdlZZowkhj77w=; b=YGCJ3ExAITh5zZVe1YUG/5kkVhQU/edoREqvWKfhx8XhUuV7UELYyst7r09lqmjY5H i7YdPxK3CJjjtPM+286kqBzR0yf2E0xsyNGFA9l/NAOqjpBGnc9e5e6HYB2fGbjNcr/A o6Q2iWTkF5m+rM9LNQHFu3KEF1PZ5NU/j0HTovsvRdbHWc9bsSQFMgBxXitWYKrhnEeg G5v8lKYGYavFINukjdHz7Eg9V68HtMrhaUfk8RQgT0prhv2O2yuqBa2hymCrgwxA8eEi agS82NaiH+EgJOMMsQlTe89lJ9msFteBhCT4K+xZpOD74lWhYHvTPH+bxMNYweGhLf4b FGeQ== X-Gm-Message-State: ALoCoQmKGJCm34mE9DDwGiO1nNhbUtpj2/LFpNwM/+IvVZUf/vP9RN74mShzuPzRkgRBA70699rN X-Received: by 10.98.75.83 with SMTP id y80mr75216399pfa.77.1448937006372; Mon, 30 Nov 2015 18:30:06 -0800 (PST) Received: from [192.168.1.102] (c-24-6-102-176.hsd1.ca.comcast.net. [24.6.102.176]) by smtp.gmail.com with ESMTPSA id qn5sm54640256pac.41.2015.11.30.18.30.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 18:30:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: mtree "language" enhancements From: Tim Kientzle In-Reply-To: Date: Mon, 30 Nov 2015 18:31:07 -0800 Cc: "freebsd-arch@freebsd.org" , Michal Ratajsky , Brooks Davis , "Simon J. Gerraty" Content-Transfer-Encoding: quoted-printable Message-Id: <71D3DCA2-B336-4849-88E3-8412F8A93324@kientzle.com> References: <0A51B6D4-9EDD-4EFF-876F-C6B515DBB4F3@kientzle.com> To: Warner Losh X-Mailer: Apple Mail (2.3096.5) 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: Tue, 01 Dec 2015 02:30:07 -0000 > On Nov 29, 2015, at 9:49 PM, Warner Losh wrote: >=20 > On Sun, Nov 29, 2015 at 9:28 PM, Tim Kientzle = wrote: >=20 >>=20 >>> On Nov 29, 2015, at 2:49 PM, Tim Kientzle wrote: >>>=20 >>> 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. >>>=20 >>> I think 'tar' got this right: If uname and uid are both specified, = then >> 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 = that >> 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. >>=20 >> On further reflection, preferring UIDs to unames would actually be = pretty >> common here. >>=20 >> In particular, NanoBSD (and Crochet and other similar tools) should = prefer >> the UID when building images instead of looking up unames against the = build >> host's password file. >=20 >=20 > 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 = in > preference to either of these alternatives. That's the most correct = thing > to do: use as much of the data as you can, as late as you can. >=20 > The thing I'm struggling with now is why would both be present? Would = that > 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 = to > avoid contamination? To set something not in the password file, or = just > comfort level of the user? FreeBSD will write unames for install*. >=20 > So I'm left thinking that maybe the rule should be 'last one wins' at = least > 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 add the user. 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 = anywhere. For #2, you must have the uname since the UID would be wrong. = An image 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 the image. So it may be reasonable to just rely on uname everywhere = for now. Tim