Re: [gentoo-dev] RFC: Userkit.eclass

[Michael Mol]

On Tuesday, November 29, 2016 04:49:24 PM William L. Thomson Jr. wrote:
> On Tuesday, November 29, 2016 10:40:20 AM EST Michael Mol wrote:
> > Highly detailed lists like that--used as a broad standard--are a bad idea.
> > They represent a single synchronization point that everyone must adhere
> > to.
>
> That is a statement based on opinion.

Of course. And then I gave examples as to why.

> You say it is a bad idea. I say it is
> necessary and needed. Otherwise wrt to Gentoo ebuilds can stomp on each
> other. Using same GID or UID in more than one ebuild causing problems.
> There has to be something know so others do not use ones others are
> already.

If Gentoo wants to do it internally, that's one thing. But I would recommend 
against inviting other distributions to use Gentoo's list, which was something 
you seemed to be suggesting. Doing so asks that Gentoo shoulder the 
bureaucratic load from other distributions that want things added to Gentoo's 
list.

>
> > That means that every prospective adjustment to the list requires active
> > maintenance. That means that for every new daemon someone writes, they
> > have
> > to go through an admissions process. For every contentious fork of a
> > project, you risk conflict over who the designated contact for the
> > assignment should be.
>
> If they package such in Gentoo someone is making a call as to what UID and
> GID should be used. If you think about it from packaging said new daemon in
> Gentoo, it is a MUST.
>
> If it does not exist, should it be entirely random from the packager
> perspective? What if they use a GID/UID specific to them and not others.
>
> There has to be some standard some consistency in Gentoo.

If you want to tie this specifically to Gentoo packaging, that's fine. Though 
I'd recommend you put the user and group allocation in the ebuild. Then your 
"list" is trivially generable by parsing portage. Further, you can *enforce* 
these allocations when calculating the dependency tree. If you're not 
enforcing them, what's the point? Is there a benefit without said enforcement?

>
> > It adds a large bureaucratic load on everyone. Every itch some developer
> > thinks about scratching has to be weighed against engaging with some
> > process- laden entity. Maybe they'll participate, but they likely won't.
>
> Gentoo shines at bureaucratic load. That may be one of the only things
> Gentoo is really good at, needless bureaucratic loads that just slow things
> down and fracture the community, exherbo, funtoo, and likely others...

I was under the impression that Gentoo was chronically undermanned for even 
the workload it has.

>
> This is not needless bureaucracy , this is necessary.

Opinion. Why is it necessary? What is it necessary for?

>
> > Have you watched the IANA ports assignment registry over the years?
> > Consider how many services and tools you've seen that *don't* respect it.
>
> Yes, how often to ports < 1024 change? Hardly ever.... Proving the exact
> point why this is needed. People can change them themselves but 99% of the
> time its to some other port > 1024.
>
> Why is there IANA port assignment registry in the first place? Likely for a
> similar reason.

How relevant even *is* the <1024 distinction any longer? Once upon a time, the 
idea was you had to have special privileges to open those ports. Now, there is 
really no reason for anyone to care; capabilities-oriented permissions 
completely obviated the need, and I can only think of ssh, telnet and ftp and 
as server services that should require special host privileges to 
operate...and that's only because they may need to be able to call setuid().

And because the <1024 port privilege distinction has been so restrictive and 
bureaucratically sloggish, applications adapted to use ports above 1024. 
Games? Sync utilities? Proxy servers? Far more commonly-observed ports are 
above 1024 than below it, and many (most?) don't even get added to IANA's 
list. *That's* why the <1024 ports don't change much; the feature is obsolete, 
and users don't bother.

As an example, I just checked on Syncthing, to see if its three ports were on 
IANA's list. They're not, and I stumbled across a Github issue where the devs 
flatly stated they didn't care.

The IANA ports list is, by and large, obsolete. It became obsolete because it 
was too much a hassle for people to participate in.

>
> > All of this is why we use identity management tools like LDAP in the first
> > place. Heck, it's why we have passwd and group files for mapping names to
> > ids and didn't simply hardcode system IDs decades ago.
>
> LDAP typical manages user accounts not system. If the LDAP server is not
> reachable you would make a system completely nonfunctional if it relied on
> LDAP for system accounts.

That's fair. Although I really like how one LDAP alternative operates over 
DNS, permitting local caching. (I can't for the life of me remember the name 
of that system, though.)

>
> Also needed from a file sharing stand point of view if sharing parts of a
> system across others. You need consistent GID/UID mappings or things like
> NFS will have lots of problems.
>
> Package a few things in Gentoo that need a UID and/or GID and you will start
> to understand the problem from a operating system packager perspective.

Oh, I understand the problem, but you haven't explained why your solution is 
the necessary solution to it, or how you would cope with the plethora of edge 
cases I brought up. It would seem there are already many established 
workarounds for the status quo, unstable-UID/GID in a cross-system context.

Now, would I like to see stable UIDs and GIDs? Sure. For a couple of years, 
I've been toying with the idea of having IPSEC AH packets tagging packets with 
the UID of the process that generated them, for diagnostic and auditing 
purposes. Stable UIDs would make that more useful.

But trying to set up a list for everyone to move in lockstep with seems to me 
like a bad way to go. Less bad if you intend to keep it unique to Gentoo, but 
the broader you make the scope, the more strain you'll put on the ecosystem as 
a whole. More daemons will be build that are intended to run as local users. 
More software will be pushed into opaque blobs a la Snap and Flatpack.

As a general rule, the bigger the hassle you make something, the less people 
will want to engage.


-- 
:wq