#442 Please recommend usage of new sysusers.d/ facility to register system users
Closed None Opened 10 years ago by lennart.

So far registration of users has been done with relatively complex shell fragments in %pre:

https://fedoraproject.org/wiki/Packaging:UsersAndGroups

I'd like to propose recommending usage of systemd's /usr/lib/sysusers.d/ drop-in facility to register system users instead. The major benefit is that this turns imperative user creation into declarative user creation, which allows us to update images of /usr with RPM, then boot into them, at which point any newly dropped-in files get processed. This is useful for stateless systems, golden master systems, and support a factory reset scheme.

Declaration of users is relatively simple:

http://www.freedesktop.org/software/systemd/man/sysusers.d.html

A package should simply drop-in a foobar.conf snippet into /usr/lib/sysusers.d/. Then, invoke from %pre invoke "%sysusers_create foobar.conf", which will create the user.

And that's it.

Given that this probably a non-trivial change I figure there needs to be some discussion on fedora-devel, which I will begin shortly.


The FPC met to discuss this ticket today, but opted to defer on taking action on it. We're going to wait for FESCo's decision on the sysusers.d feature request. If approved, we'll document it accordingly.

We would however ask that the sysusers.d tooling first support the use case where a system user is created (e.g. "spotd") but no identical group (e.g. "spotd") is created. This is an existing scenario where multiple system users end up being in a single group and we do not need unnecessary groups to be created.

It was not entirely clear whether this was currently possible from the man page (the implication is that the "spotd" group would automatically be created via the "u" line, even if a "g" line is present).

FPC Vote Tally: (+1:6, 0:0, -1:1)

Let's put this on hold for now. During the discussion on fedora-devel there were a number of things raised that I need to improve in sysuers first.

Is there any progress on this?

The packaging committee is still awaiting additional information before it can properly address your request. Please provide that within the next month or this ticket will be closed. (Of course, you can always reopen it if the situation changes) Thanks!

I'll go ahead and close this, but you are welcome to reopen it or file a new ticket whenever you would like to move forward.

%sysusers macros has been deployed in Fedora, Can we update the page -> ?

https://fedoraproject.org/wiki/Packaging:UsersAndGroups

We don't know what to update it to. The sysuser stuff doesn't even work properly as of now (because it fails to interact with the audit subsystem). In its current state I don't think we want to suggest to anyone that they should use it at all.

A draft will be coming our way when it's ready. (@sgallagh indicated to me that would be happening.) Until then there's nothing for us to do.

Metadata Update from @tibbs:
- Issue close_status updated to: None (was: Fixed)

6 years ago

The sysuser stuff doesn't even work properly as of now (because it fails to interact with the audit subsystem). In its current state I don't think we want to suggest to

@tibbs do We have a bug report about that ?

Truthfully, the audit subsystem thing is a bit of a red herring, as we have COUNTLESS ways that users get added to the system without triggering that audit message, but we're going to address it nonetheless.

As @tibbs says, I'll be putting together a draft to vote on as soon as this goes through a proper shakedown, which may take a couple weeks. I agree that our official stance right now should be "please do not use this yet".

The sysuser stuff doesn't even work properly as of now (because it fails to interact with the audit subsystem). In its current state I don't think we want to suggest to

@tibbs do We have a bug report about that ?

It just came up on a devel-list thread and @zbyszek was taking it to upstream. I don't know if a formal bug is tracking it yet, but I'll ask that @zbyszek mention it here when it is.

the mailing list covered this

Date: Tue, 6 Mar 2018 09:24:27
From: Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl
Reply-To: Development discussions related to Fedora
devel@lists.fedoraproject.org

How does this interact with useradd and groupadd? Does this replace
them? And if so, does this send the required audit events?

It's a very simple tool to create system users and group in /etc/passwd.
It just creates entries in /etc/{passwd,group,shadow}, and does not
interact with audit in any way afaik.

Date: Tue, 6 Mar 2018 11:15:45
From: Steve Grubb sgrubb@redhat.com

Is there some guideline that requires an audit log message to occur
whenever a user is added to a system?

Yes. Absolutely. Even if that user is a system account.

later (still sgrub)

OK. We need it to. I can help you with the events if you can point me
to the code that creates the account/group.

Thanks,
-Steve

===========
@ itamarjp

as you were asking on a closed ticket, I provided the context

I am not aware of any such filing

if your consultation with sgrub or otherwise indicates one, please also note it here

but really this question shows the problem of using mailing lists and ticketing systems, rather than Bugzilla

FTR, the result (so far) of this discussion was:

On Wed, Mar 07, 2018 at 01:07:15PM +0100, Steve Grubb wrote:

On Tue, 6 Mar 2018 16:31:29 +0000
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:

I assume that there some standarized log message to be emitted in this
case? If this is documented somewhere, we could add that, although
it'd probably be easier if somebody who knows audit submitted a pull
request. The sysusers code is at
https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1205.

It will take me a couple days to get to this, but its simple enough I
can just add the events. This trick is that they must match exactly
the same format that shadow-utils sends. (I also wrote the patch for
shadow-utils.)

@sgallagh what is the state of this? can we re-open this issue?

Log in to comment on this ticket.

Metadata