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

[Alan McKinnon]

On 30/11/2016 01:13, William L. Thomson Jr. wrote:
> 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

Or that. Don't fixate on the tool or it's name, the question is about
your stateent of duplicate UIDs and GIDs. I responded with "how would
that occur?" and gave 2 scenarios I could think off of the bat

>
>> 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...

chown/chgrp/chmod is not a chore. It is REQUIRED when moving files
around from system to system. Aside from the possibility of uid/gid
differing there is also umask in the mix which pretty much forces you to
chmod anyway. If you need to do that you might as well chown/chgrp as
well to be 100% sure.

I routinely and often do all the above at work, moving files between
FreeBSD, Ubuntu, Centos, Solaris and whatever container technology
du-jour the devs decided was teh coolz awes0me today. And powershell on
Unix plus posix/cygwin/bash on Windows. I have zero guarantees about any
id consistency in that mess^Wreal-life-ISP-network, so what difference
is Gentoo going to make?

>
> Or worse you mix stuff and give something improper permissions and really mess
> up security...

That's what chmod and eyeballs are for

>
>> 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.

OK, so you could force code into repoman to do what you want. You still
have to convince all other devs that it's a good idea
>
>
>> 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.

See above about what I do on a real life network. Daily. For 15 years
now and counting.

>
> Say you do a fresh install. What if all your UID/GID differ from your backup?
> HUGE MESS!!!!

So deal with it. That's what chmod is for.

Or do you reinstall, restore backups and then NOT check all details
thoroughly?

>
>> 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.

Describe these cases please. I've got 15 years behind me at this and
probably seen it all, but I'm just not seeing the problem you perceive

>
>>> 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.

See above. I submit this problem does not really exist, that the real
solution is chmod/chown/chgrp/attention and eyeballs. Which you pretty
much have to do anyway for other reasons than lack of consistency around
UID/GID. Like umask, SGID on directories

[ snip ]

>> I have packaged a few things in Gentoo (privately only)
>
> Try doing it for the public, which will end up with thousands of installs.

I'm still not seeing it. You can have a million installs from an ebuild
available to the public, and the vast majority are completely isolated
from each other.

>
>> , 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.

Let's look at real life.

I have exim mail servers on FreeBSD, Ubuntu and Centos. Now that's a
typical real-life scenario, and they are different deliberately.
Shuttling the mail spool from one machine to another is a fairly lengthy
scp/rsync operation followed by a very fast chmod & chown and daemon
start. The saving is maybe 2 seconds in something that takes many minutes.

How about my name servers? They are also a mix and the hosted domains
are in cvs. The bind user does not have a shell and root doesn't get to
cvs update.

Now these are typical ordinary everyday sysadmin actions, and trying to
register standard UIDs on Gentoo does nothing to shave seconds off the
full process. So why bother? It would be optimizing for the less common
case.

I could also describe the enormous collection of jar files the devs want
dropped into new tomcat installs from any of several source code repos.

> 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...

I'm starting to think that you need more experience with real-world
deployments with things other than Gentoo in them. Your position only
affects Gentoo and does nothing to assist with the same circumstance on
everything that is not Gentoo - the common case.

The real problem here is not inconsistency, because that is something
you will never fix. The problem is the design of Unix itself and what
goes into inodes - a 16 bit number that maps to a name for the benefit
of humans. Syncing files between machines was never really envisaged -
humans worked with named and the IDs were whatever passwd said they
were. So as long as you picked a UID and stuck with it, all was good.
So you have a system where the UID can be any 16 bit number you want it
to be, and THAT is the real problem - people DID make it anything they
wanted it to be. That genie is long since out of the bottle and isn't
going back in.


-- 
Alan McKinnon
alan.mckinnon@×××××.com