On 6/22/23 19:55, Steve Grubb wrote:
Hello,
On Thursday, June 22, 2023 11:01:28 AM EDT Zbigniew Jędrzejewski-Szmek wrote:
2. systemd provides users and groups that are actually owned by the setup
package. As rpm is now turning non-root file ownership into dependencies,
systemd could end up pulled in where setup is needed (eg early install
stage) which will not end up well. So systemd will need to stop providing
users it does not actually own.
I was hoping we would be make the dependency on setup optional.
It is a fairly heavyweight package (700+ kb) and with lots of
not-that-useful-on-a-typical-modern-installation stuff (mail alias support,
csh profile, /etc/hosts, nfs exports, etc.). Most of this is tiny, but it
clutters /etc, which ideally would be empty, and also /etc/services is 700
kb. setup is currently pulled in by dependencies, but e.g. in the initrd
we should be fine without it. (And the same applies for e.g. minimal
container images without login users or a shell.)
There are several trusted databases there that things like getservbyport
consult. I would think csh stuff could be installed by tcsh.
Maybe the non-essential stuff could be split out into a new
subpackage, with setup only providing /etc/{passwd,group,shadow,gshadow}
with the base set of users and groups, and all other files moved to
setup-clutter.
I think a few more files than that are still needed. But it could use some
pruning.
3. The various %sysuser_()* macros in systemd-rpm-macros need to be
phased
out. As it'll be a long time before the sysusers feature is in all Fedora
versions, it needs a longer term plan. One simple possibility is do what
was done with all those ldconfig from %post back then: change the
%sysusers_() macros to no-ops in rawhide to let rpm handle it, and only
actually bother updating packages once all relevant versions have the
sysusers feature.
+1 to this plan.
4. The sysusers "hook" in rpm needs to be enabled (uncomment
%__systemd_sysusers macro in rpm). It wont do anything at all before 1)
and 3) are done though.
6. The user/group dependencies for non-root users need to be turned into
hard requires (initially these are just recommends). I would be suprised
if this doesn't cause some disruption somewhere, although the content
that is not root:root owned is pretty scarce these days.
7. Packages creating or using non-root user/group need to be rebuilt.
7. One day a few years from now, replace
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
with "supply a sysusers file for your needs"
In reality, it'll need adjusting long before that and for that, it'll
need
FPC recommendations and all.
8. Remove all user/group addition related macro and script fubar from
specs for good. The first commit in rpm source tree is from 1995, it'd
be a nice 30 year celebration... but I don't expect it to happen quite
that soon. Maybe in 2035 new people will start look at old specs in
horror, "What do you mean they had to deal with all this user/group
stuff manually! For 30 years!"
I've begun from 1) now:
https://src.fedoraproject.org/rpms/systemd/pull-request/109
This is merged now and the package is built. (I guess it's probably in
gating now.)
https://src.fedoraproject.org/rpms/rpm/pull-request/45
After those have been done, people can start experimenting with the
feature. I don't remember seeing an actual Fedora Change for either
file-trigger enablement or current %sysuser_* macros so I'm not sure
it's needed here either?
https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
I would caution against this whole proposal. Not that I'm against it, but
just saying be careful doing it. People often forget about our security
concerns. Currently, shadow-utils has about 400 places which generate audit
events during the managing of system and user accounts. libuser (I saw the
deprecation email) has 55 places where it sends audit events managing
accounts.
There is a 10 year old (or more) standard published here:
https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Account-Lifecycle-Events
If %pre getent, useradd, and groupadd are being replaced by something, that
something needs to conform to the expected security safeguards that currently
exist. It needs to match the kind of events and the format that currently
exists.
Rpm's sysuser integration simply calls out to the configured helper to
do the heavy lifting. By default that's systemd-sysusers, I have no idea
what audit events if any it generates, but it's entirely possible to
replace that with a script that calls out to useradd and groupadd instead.
The system accounts still need to be accessible by the getpw* family of
functions or there could be a lot of breakage.
Uh, yes? Users and groups do need to be created. We're merely talking
about letting rpm automate the task based on already packaged sysusers.d
files instead of requiring packagers to fill out tedious boilerplate to
handle it.
On a somewhat related note, we're considering to make rpm only ever look
at local passwd/group files for user/group info as that's the only info
that is reliably available to rpm:
https://github.com/rpm-software-management/rpm/pull/2503, @keszbyz
summarizes it nicely here:
https://github.com/rpm-software-management/rpm/issues/882#issuecomment-1504837548
- Panu -
-Steve
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
