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
signature.asc
Description: This is a digitally signed message part.
