public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Thomas Deutschmann <whissi@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)
Date: Tue, 10 Dec 2019 13:26:44 +0100	[thread overview]
Message-ID: <29e0b831-a578-c156-a442-9f4fe1d91a5e@gentoo.org> (raw)
In-Reply-To: <CAGfcS_kbewv2Px074PE=L-1aaW6pGL3osttLQ1nbbBisn801Yg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1501 bytes --]

Hi,

On 2019-12-10 12:47, Rich Freeman wrote:
> Having UIDs chosen completely at random seems fairly non-optimal.
> Suppose you're building containers/etc and then bind-mounting in
> persistent storage (/var/lib/mysql and so on).  Wouldn't it be nice if
> the default were that mysql would get the same UID on every build?  I
> guess you could provide an initial /etc/passwd on every fresh build
> but it just seems like an extra step.

While this sounds like a valid problem we are going to address, this
sounds like an analysis without practical experience:

In practice you will *never* assume proper container <> host user
mapping. *Never*. If you do that, you are doing it wrong:

- Container sometimes switch base images. You won't notice that unless
you follow container provider very closely. But you are using container
because you are focused on containerized application, not the container
itself...

- Container start doing things differently. Again, you won't notice, see
above.

- Your host is maybe running some real services. You really don't want
that a container suddenly become able to access these services just
because container <> host mapping has match.

No, when you follow best practice you will always pass user/group or use
other available mapping solutions.

So while it sounds like a valid *goal*, in real world, it isn't.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

  reply	other threads:[~2019-12-10 12:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-09  8:17 [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing) Michał Górny
2019-12-09  9:44 ` Ulrich Mueller
2019-12-09 10:00   ` Ulrich Mueller
2019-12-09 16:54 ` Thomas Deutschmann
2019-12-09 17:47   ` Ulrich Mueller
2019-12-09 18:02     ` Thomas Deutschmann
2019-12-09 18:48       ` Ulrich Mueller
2019-12-09 20:10         ` Thomas Deutschmann
2019-12-10 14:36           ` Michael Orlitzky
2019-12-09 21:48 ` Alec Warner
2019-12-10  5:28   ` Michał Górny
2019-12-10  5:44 ` Joonas Niilola
2019-12-10 11:47   ` Rich Freeman
2019-12-10 12:26     ` Thomas Deutschmann [this message]
2019-12-10 12:44       ` Rich Freeman
2019-12-10 13:25         ` Thomas Deutschmann
2019-12-10 13:48           ` Rich Freeman
2019-12-10 16:05     ` Joonas Niilola
2019-12-10 16:25       ` Michael Orlitzky
2019-12-10 13:34   ` Michał Górny
2019-12-10 16:13     ` Joonas Niilola
2019-12-10 16:17       ` Michał Górny
2019-12-10 14:50 ` Michael Orlitzky
2019-12-10 15:04   ` Michał Górny
2019-12-10 15:54   ` Rich Freeman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29e0b831-a578-c156-a442-9f4fe1d91a5e@gentoo.org \
    --to=whissi@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox