public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Stefan Behte <craig@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] A policy to support random superuser account names
Date: Sun, 02 May 2010 17:13:18 +0200	[thread overview]
Message-ID: <4BDD968E.7050309@gentoo.org> (raw)
In-Reply-To: <20100430200726.298ae94c@pomiot.lan>

Hi,

in some environments you have to rename "root" to something else, just
to be compliant to a (maybe dumb) security policy. This might be the
case for PCI, and as far as I remember, it is necessary (not just
"recommended") for a BSI Grundschutz certification (meaning something
like "basic security protection") [1]. Unfortunately I didn't find the
exact link.
This might prevent or make usage of gentoo more complicated in those
environments, but is only a problem for a small fraction of our user base.

Best regards,

Craig


[1]
https://www.bsi.bund.de/cln_183/ContentBSI/EN/Publications/Bsi_standards/standards.html

30.04.2010 20:07, Michał Górny wrote:
> Hello,
> 
> I would like to put an emphasis on the fact that many eclasses
> and ebuilds in gx86 are relying on an assumption that the superuser
> account is always supposed to be named 'root'.
> 
> In fact, no such constraint exists. Although most users will never even
> think of changing the superuser account name, it is perfectly legit
> to do so, and to use any name for that account. Moreover, it is
> perfectly legit to name an unprivileged user 'root' too.
> 
> Thus, the above assumption is clearly incorrect and may result in many
> issues with ebuilds using it. These range from builds failing because
> of chown 'invalid user' error to packages being installed with
> incorrect file ownership.
> 
> From what I've heard already, similar problem has hit Gentoo/*BSD users
> already, with superuser group not being named 'root'. Although some
> files were fixed to properly use numeric GID in the specific case,
> no UID-related changes were done.
> 
> Moreover, not all developers agree with the case being an issue,
> and they even refuse patches clearly fixing it [1]. Thus, I guess that
> a clear policy regarding referencing the superuser account should be
> enforced.
> 
> In my opinion, that policy should clearly indicate that the numeric
> UID/GID should be always used for referencing the superuser account
> as they are fixed unlike the names.
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=315779
> 




  parent reply	other threads:[~2010-05-02 15:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-30 18:07 [gentoo-dev] A policy to support random superuser account names Michał Górny
2010-04-30 18:29 ` Fabian Groffen
2010-04-30 19:36 ` Alec Warner
2010-04-30 19:36 ` Alec Warner
2010-05-02 21:57   ` Enrico Weigelt
2010-05-03  7:31     ` Michał Górny
2010-05-04 19:19       ` Mike Frysinger
2010-05-02 15:13 ` Stefan Behte [this message]
2010-05-02 15:23   ` Krzysztof Pawlik
2010-05-02 18:52     ` Stefan Behte
2010-05-02 22:06     ` Enrico Weigelt
2010-05-02 22:00   ` Enrico Weigelt

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=4BDD968E.7050309@gentoo.org \
    --to=craig@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