[arch-general] Arch pkg user and group IDs?

[Leonid Isaev]

On Sun, Nov 27, 2016 at 10:32:38PM -0500, Eli Schwartz via arch-general wrote:
> On 11/27/2016 10:03 PM, Leonid Isaev wrote:
> >> Well, packages can have files that need to have a specific system
> >> user ownership. That is why the UID/GID database exists, right?
> >> Because the UID baked into the *.pkg.tar.xz has to match
> >> /etc/passwd, and systemd-sysusers can't inherently do anything that
> >> repetitive useradd + getent scripting wasn't always capable of.
> > 
> > For example, dnsmasq ships /usr/lib/sysusers.d/dnsmasq.conf which
> > contains 'u dnsmasq - "dnsmasq daemon" /' and on my system the user
> > dnsmasq has (randomly-generated) ID = 997. Such packages won't have
> > any files owned by a non-root user because they don't know the UID.
> 
> Let's rephrase that. Some packages contain software which requires
> runtime files owned by a non-root user associated with the software.
> 
> The fact that they don't know the UID during makepkg is precisely the
> reason why the UID/GID database exists...

Yes, if such packages exist, then of course, they would require hardcoded UID.

> > Yes, why not? You can override files in /usr/lib/sysusers.d with
> > files in /etc/sysusers.d having identical names, no? For example, on
> > my workstation, there are only 23 lines in total where UID need to be
> > changed below 500.
> 
> Because that is the classic definition of working around buggy software?
> useradd/sysusers was carefully designed to be able to dynamically
> allocate UIDs and now you have to copy and override every single
> sysusers definition because systemd won't let you configure the
> allocation range...

I kinda agree with Lennart Poettering here as to why systemd shouldn't read
login.defs at runtime. Still, dealing with systemd ppl sucks...

I mean once you do change ranges in login.defs, you'll have to fix user
memberships as well, yes?

> > Of course, this needs to be done for all Arch machines.
> 
> Plus that.

Not only that, but also updates must be carefully monitored...

> > That is why I think that changing ownership in NFS share is a better
> > idea...
> 
> Well, depending on the number of files...
> Anyway, modifying a single file in a very predictable manner on multiple
> *new* machines is an even better idea. Plus, Hauke Fath indicated that
> there were also plenty of files scattered across 50 other existing machines.

Hmm, I thought all /home's were on an NFS share... But I still don't understand
why is it such a difficult task?

Sure, migrating 10 year old installations this way is not pleasant, but at
least this will be future-proof. Because how do you avoid clashes with
hard-coded UID in packages now?

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
                  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D