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 >
