From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E7657138334 for ; Tue, 10 Dec 2019 13:48:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73BA0E09D6; Tue, 10 Dec 2019 13:48:39 +0000 (UTC) Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3955FE09D1 for ; Tue, 10 Dec 2019 13:48:39 +0000 (UTC) Received: by mail-pg1-f172.google.com with SMTP id a33so8725214pgm.5 for ; Tue, 10 Dec 2019 05:48:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=icj7jzZ2vCF5uSQxlrsJM5zYx/6WsmS/yDmzIzKSYNo=; b=SwMxC7LTfrZ3O9rO0PEg664v7ctEXBN3M9Q4/a+UXt/Hq97cmgNPsPj/Wf9s67k+v2 v1pPo/OITZ8TO63YjRHZup/7DgSfKw64CMiWteCgPPZYdba4/OF7hc20llPIxTRfWM/I rGJAhmBtCr68B3TOru1O3LgpFHcPh692iKUKxpEke66aSVaV1Xb6L1lWM0G2vr+Y9Ckj fCmzWrpxcIp2FkiVng3OKLheyn5SOGDmlYuUXO4ndAfCW5YZvF0+6O/XHLZAwx7q6f/P dAXmaAlLJ4KvkH+fDoM3pJIqsNNmcxYczioN4HVuNwLRITch9/Rn3tZPwJeEN7fkL5Li a/5Q== X-Gm-Message-State: APjAAAVTBdqOQVQZSUfmJDDMO16allhRNxQmHmWfeDyBJtszBBuTE0zY S4mRwdtOlUpvecGlTQQwsyHblTW3ar1guyx/OSgYswXT X-Google-Smtp-Source: APXvYqypFK+DE+6UP7/k3GlJKEMC+2ULtL+8GdZgdG5WXkmdFZ3m2Y3Kr6Qq9Un8yT6V2RqTMeCsAtiZ6CJWqcve5h0= X-Received: by 2002:a63:8041:: with SMTP id j62mr24757859pgd.41.1575985717474; Tue, 10 Dec 2019 05:48:37 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <84a435bffe460efd2620ceec0c0405fa18a7937b.camel@gentoo.org> <6f1dc9b3-e13e-1186-f75a-51615db505d3@gentoo.org> <29e0b831-a578-c156-a442-9f4fe1d91a5e@gentoo.org> <648f9c32-fd26-1725-7b54-9ba08322e42f@gentoo.org> In-Reply-To: <648f9c32-fd26-1725-7b54-9ba08322e42f@gentoo.org> From: Rich Freeman Date: Tue, 10 Dec 2019 08:48:25 -0500 Message-ID: Subject: Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing) To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: a325d076-d833-48d6-9a9f-f53cf0bf8031 X-Archives-Hash: e39515bc3f4623b785afa0de966cf457 On Tue, Dec 10, 2019 at 8:25 AM Thomas Deutschmann wrote: > > On 2019-12-10 13:44, Rich Freeman wrote: > > I'm not talking about container-host mapping. I'm talking about > > building the same container 100 times and having the container end up > > with the same UIDs inside each time. > > > > Build order in portage isn't really deterministic, especially over > > long periods of time, so you can't rely on stuff getting installed in > > the same order. > > Assume you are building a container for dev-db/mysql. I can only think > of one scenario where you would end up with different UIDs: That's when > dev-db/mysql (or a dependency) would suddenly create an own user and > will be merged before mysql's user was created. > > But this is very theoretically. Especially in a container world, you > will create one container per services so it's *very* unlikely that > something like that will ever happen. Not? There are cases where you might have more than one service in a container, and there is certainly the issue of dependencies. It certainly makes sense to limit a container to a single function, but internally that could involve multiple processes. > Aside benefits from reproducible builds in general (which Gentoo doesn't > provide), please share reasons why one would care about used UIDs/GIDs > in containers... Well, that is simple. In the mysql example /var/lib/mysql would be bind-mounted from outside the container, since it needs to be persistent anytime the container is updated. If you update the container and it ends up with a different UID for mysqld, then it wouldn't be able to read anything in /var/lib/mysql as it would still have the previous UID. You'd need to keep the two in sync somehow. In fact, that is the very example you go on to offer... > > Uh, the container processes shouldn't even see the host > > processes/files whether they have the same UIDs or not... > > Especially when you put mysql or any other service using data into a > container, service running in that container must be able to access this > data. And one common way to do that is allowing container to access data > stored on host, i.e. > > > $ docker run \ > > --name some-mysql \ > > -v /my/own/datadir:/var/lib/mysql \ > > -e MYSQL_ROOT_PASSWORD=my-secret-pw \ > > -d mysql:tag > > which will make /my/own/datadir from host available in container as > /var/lib/mysql. > This is obviously exactly how you'd do it if you were using docker, but you don't need to keep the UID in the container in sync with anything else in the host. If security is a concern you'd probably want to make sure that nothing non-root can reach the directory since its UID might be in use for something else. In any case, this is why consistent UIDs in scratch installs are useful. When you're building a new version of a container you don't want all its UIDs to change. And of course this isn't just limited to containers, but anything where you have persistent storage. It is just that the idea of creating new instances from scratch instead of updating them in-place has become more fashionable around the same time that containers have become more fashionable. You could do the same thing with a bare-metal host, though it would be a bit more painful (perhaps using A/B partition booting, or less painful if you're booting from a SAN or something like that). -- Rich