On Tue, Mar 6, 2018 at 9:24 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Mar 06, 2018 at 01:03:30PM +0100, Steve Grubb wrote:
> > On Mon, 5 Mar 2018 23:11:12 +0000
> > Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote:
> >
> > > - somewhat independently, systemd-sysusers has been beefed up so it is
> > >   possible to use it to create system users before any files are
> > >   installed on disk, but honouring admin overrides. In short, we now
> > >   recommend the following invocation to create users for an rpm which
> > >   contains files owned by those users:
> > >
> > >     %sysusers_create_package %{name} %SOURCEN
> > >
> > >   where %SOURCEN is the tmpfiles.d config file which will be installed
> > >   by package. This expands to
> > >
> > >     echo "u NAME - -" | systemd-sysusers
> > > --replace=/usr/lib/sysusers.d/NAME.conf - >/dev/null 2>&1 || :
> > >
> > >   and the "u NAME - -" configuration is applied with a priority that
> > >   /usr/lib/sysusers.d/NAME.conf normally has (so e.g.
> > >   /etc/sysusers.d/NAME.conf will override this).
> > >
> > > [1] https://raw.githubusercontent.com/systemd/systemd/master/NEWS
> >
> > 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.
>


Is there some guideline that requires an audit log message to occur
whenever a user is added to a system? We can't necessarily know on every
end-user system when a user is added by a central authority like FreeIPA,
for example. Even if we only limit it to dealing with /etc/passwd and
friends, there are still plenty of ways for this file to be modified that
wouldn't cause it to trigger an audit event unless we added a service to
monitor with inotify or similar.

So, I don't see this being any worse than the current state of the art.
Realistically, such an audit event is useless and noisy; whether a user is
*available* is not interesting in comparison to when that user logs in.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to