On Wednesday, November 30, 2016 12:49:44 AM EST Alan McKinnon wrote: > > Why would you end up with duplicated UIDs and GIDs? The only real ways > that can happen is > - ebuild "edits" passwd and group directly using echo/sed and the like. > - ebuild runs useradd|groupadd specifying the uid/gid as arguments
I think you mean enewgroup and enewuser > Both of which are silly. Just use useradd/groupadd without uid/gid > arguments. The utility will make sure the uid/gids are non-duplicate, > and ensure they are <1000 or whatever for system accounts Randomly chosen GID and UID are a problem in the making. If you haven't experienced such yet, give yourself time. Moving files between systems, you have to chown/chgrp, etc it is NOT fun... Or worse you mix stuff and give something improper permissions and really mess up security... > How do you intend to MAKE devs follow it? More eternal bike-shedding? A nifty tool called repoman which could do a quick lookup. As could enewgroup/ enewuser. They could hit the list/database. If something is trying to use existing error, etc. Otherwise process to reserve it, etc. > Who cares what the uid/gid is? There's a range of about 950 to chose > from. The way to ensure a filesystem object has the correct owner and > group is by using chown/chgrp. See above, any administrator moving files between systems, restoring backups, etc. Say you do a fresh install. What if all your UID/GID differ from your backup? HUGE MESS!!!! > Except for a few cases out on left field (like nfs shares - a problem > that nfs must fix) you don't really care what the uid/gid is, as long as > it's not duplicated. The thing you care about is the NAME Not really just cases you haven't run into yet, which can be very common. > > This is not needless bureaucracy , this is necessary. > > This is a joke right? Not at all, others are clearly not aware of all the potential issues, having not experienced them first hand, yet.... Work with enough systems, move files around, share lots of stuff, restore backups, you will start to see a major need. > >> 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. > > It's so that things like browsers, email tools and the like can drop > > :<port> for the most part and be reasonably sure stuffs will still work. > > Of the 65535 +-1 possible port numbers, only the first 1024 are truly > important, and of those less than about a quarter are in common use > (wild guess). Most of the UID/GID I speak of are below 1000. System accounts, daemons, etc. Very likely the exact same stuff running on privileged ports but not all. > The next 10,000 or so are not standards by any means, just a list of > stuff that happens to have been seen in the wild. Apps can and do pick > any old port they feel like - witness the several things that will use > 5000 out the box. Is this a problem? Not really, as very very few > machines out there will install two apps both trying to use port 5000 by > default. Nor would that ever be with any system. All *nix systems have a reserved UID/ GID range and users stuff starts above that. Some 500, others 1000, etc. > I have packaged a few things in Gentoo (privately only) Try doing it for the public, which will end up with thousands of installs. > , and written > more shell installers, puppet manifests, ansible playbooks and user > account deployers than I care to recall; I've never run into this > problem that I couldn't solve trivially - usually by just knowing the > username|groupname and looking up the corresponding uid/gid. Really, > it's just data mapping and we have tools to do the lookup real fast. Clearly you haven't come across it yet, and likely because experience has differed. But I have given you a few examples of how this could happen to anyone and why there would be a need. Say it is a failed mail server, and you need to take the queue/spool to another. Same with print, or other jobs... You need them to have the same UID/ GID, or you end up wasting MORE time syncing them to the system they go onto. Much easier to ensure all are the same. This goes for many other things. Lots of data gets owned by system accounts. Moving that data from system to system, with different UID/GIDs is a nightmare... -- William L. Thomson Jr.
signature.asc
Description: This is a digitally signed message part.
