Re: systemd 238 and sysusers

[Simo Sorce]

On Wed, 2018-03-07 at 16:23 +0100, Jakub Hrozek wrote:
> > On 7 Mar 2018, at 15:53, Stephen Gallagher  wrote:
> > 
> > 
> > 
> > On Wed, Mar 7, 2018 at 9:50 AM Simo Sorce  wrote:
> > On Wed, 2018-03-07 at 14:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> > > > On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> > > > > Yes, SSSD monitors those files and automatically cleans its cache.
> > > > > 
> > > > > However, you're right. On systems not using SSSD (which I suspect is a
> > > > > nontrivial number of systems running systemd...), people are probably 
> > > > > still
> > > > > using nss and we should call `nscd -i passwd` (plus `group` and 
> > > > > `shadow`
> > > > > where appropriate) if the nscd service is running.
> > > > 
> > > > nscd is supposed to monitor these files, too.
> > > > 
> > > > But is this monitoring sufficient?  RPM will immediately start
> > > > installing files after the scriptlet has finished.  nscd and SSSD
> > > > may not have completed their cache invalidation at this point, so
> > > > this looks like a race condition to me.
> > > 
> > > That sounds like a bug in the cache implementation. nscd and sssd
> > > simply _must_ ensure that their copy of passwd is the latest one.
> > > Shouldn't be a problem to call fstatat() before generating an answer
> > > an invalidate the cache if it returns a different mtime then previously.
> > 
> > The fast cache we provide from sssd is read directly by the client
> > (sssd nsswitch plugin) without the involvement of the sssd daemon (or
> > it would be slow).
> > so there are windows for races if you change a passwd file and then
> > immediately read out of the fast caches.
> > This is not something we can fix without severely compromising
> > performance, which is the raison d'etre of those caches.
> > 
> > 
> > Probably the simplest solution for sysusers would be to execute the change 
> > and then run a wait-loop calling `getpwnam()` until it 
> > gets a successful result (or some reasonable timeout expires, indicating a 
> > bug elsewhere). That way, it can be trusted that sysusers won't return 
> > until the user addition is truly valid.
> 
> btw if nss_sss wouldn’t find the user, then, assuming the default order on 
> Fedora, the request would just fall back to nss_files. So I don’t think the 
> race condition when /adding/ a user is something to worry about. But the 
> other way around, if the user was removed, there can be a small race between 
> removing the user and nss_sss having its cache flushed. I don’t think this is 
> any different from nscd either.
> 
changing or removing users are the cases where races matters, just
adding is not indeed.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Jakub Hrozek]

> On 7 Mar 2018, at 15:53, Stephen Gallagher  wrote:
> 
> 
> 
> On Wed, Mar 7, 2018 at 9:50 AM Simo Sorce  wrote:
> On Wed, 2018-03-07 at 14:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> > > On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> > > > Yes, SSSD monitors those files and automatically cleans its cache.
> > > >
> > > > However, you're right. On systems not using SSSD (which I suspect is a
> > > > nontrivial number of systems running systemd...), people are probably 
> > > > still
> > > > using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
> > > > where appropriate) if the nscd service is running.
> > >
> > > nscd is supposed to monitor these files, too.
> > >
> > > But is this monitoring sufficient?  RPM will immediately start
> > > installing files after the scriptlet has finished.  nscd and SSSD
> > > may not have completed their cache invalidation at this point, so
> > > this looks like a race condition to me.
> >
> > That sounds like a bug in the cache implementation. nscd and sssd
> > simply _must_ ensure that their copy of passwd is the latest one.
> > Shouldn't be a problem to call fstatat() before generating an answer
> > an invalidate the cache if it returns a different mtime then previously.
> 
> The fast cache we provide from sssd is read directly by the client
> (sssd nsswitch plugin) without the involvement of the sssd daemon (or
> it would be slow).
> so there are windows for races if you change a passwd file and then
> immediately read out of the fast caches.
> This is not something we can fix without severely compromising
> performance, which is the raison d'etre of those caches.
> 
> 
> Probably the simplest solution for sysusers would be to execute the change 
> and then run a wait-loop calling `getpwnam()` until it gets 
> a successful result (or some reasonable timeout expires, indicating a bug 
> elsewhere). That way, it can be trusted that sysusers won't return until the 
> user addition is truly valid.

btw if nss_sss wouldn’t find the user, then, assuming the default order on 
Fedora, the request would just fall back to nss_files. So I don’t think the 
race condition when /adding/ a user is something to worry about. But the other 
way around, if the user was removed, there can be a small race between removing 
the user and nss_sss having its cache flushed. I don’t think this is any 
different from nscd either.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Stephen Gallagher]

On Wed, Mar 7, 2018 at 9:50 AM Simo Sorce  wrote:

> On Wed, 2018-03-07 at 14:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> > > On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> > > > Yes, SSSD monitors those files and automatically cleans its cache.
> > > >
> > > > However, you're right. On systems not using SSSD (which I suspect is
> a
> > > > nontrivial number of systems running systemd...), people are
> probably still
> > > > using nss and we should call `nscd -i passwd` (plus `group` and
> `shadow`
> > > > where appropriate) if the nscd service is running.
> > >
> > > nscd is supposed to monitor these files, too.
> > >
> > > But is this monitoring sufficient?  RPM will immediately start
> > > installing files after the scriptlet has finished.  nscd and SSSD
> > > may not have completed their cache invalidation at this point, so
> > > this looks like a race condition to me.
> >
> > That sounds like a bug in the cache implementation. nscd and sssd
> > simply _must_ ensure that their copy of passwd is the latest one.
> > Shouldn't be a problem to call fstatat() before generating an answer
> > an invalidate the cache if it returns a different mtime then previously.
>
> The fast cache we provide from sssd is read directly by the client
> (sssd nsswitch plugin) without the involvement of the sssd daemon (or
> it would be slow).
> so there are windows for races if you change a passwd file and then
> immediately read out of the fast caches.
> This is not something we can fix without severely compromising
> performance, which is the raison d'etre of those caches.
>
>
Probably the simplest solution for sysusers would be to execute the change
and then run a wait-loop calling `getpwnam()` until it
gets a successful result (or some reasonable timeout expires, indicating a
bug elsewhere). That way, it can be trusted that sysusers won't return
until the user addition is truly valid.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Simo Sorce]

On Wed, 2018-03-07 at 14:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> > On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> > > Yes, SSSD monitors those files and automatically cleans its cache.
> > > 
> > > However, you're right. On systems not using SSSD (which I suspect is a
> > > nontrivial number of systems running systemd...), people are probably 
> > > still
> > > using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
> > > where appropriate) if the nscd service is running.
> > 
> > nscd is supposed to monitor these files, too.
> > 
> > But is this monitoring sufficient?  RPM will immediately start
> > installing files after the scriptlet has finished.  nscd and SSSD
> > may not have completed their cache invalidation at this point, so
> > this looks like a race condition to me.
> 
> That sounds like a bug in the cache implementation. nscd and sssd
> simply _must_ ensure that their copy of passwd is the latest one.
> Shouldn't be a problem to call fstatat() before generating an answer
> an invalidate the cache if it returns a different mtime then previously.

The fast cache we provide from sssd is read directly by the client
(sssd nsswitch plugin) without the involvement of the sssd daemon (or
it would be slow).
so there are windows for races if you change a passwd file and then
immediately read out of the fast caches.
This is not something we can fix without severely compromising
performance, which is the raison d'etre of those caches.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> >Yes, SSSD monitors those files and automatically cleans its cache.
> >
> >However, you're right. On systems not using SSSD (which I suspect is a
> >nontrivial number of systems running systemd...), people are probably still
> >using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
> >where appropriate) if the nscd service is running.
> 
> nscd is supposed to monitor these files, too.
> 
> But is this monitoring sufficient?  RPM will immediately start
> installing files after the scriptlet has finished.  nscd and SSSD
> may not have completed their cache invalidation at this point, so
> this looks like a race condition to me.

That sounds like a bug in the cache implementation. nscd and sssd
simply _must_ ensure that their copy of passwd is the latest one.
Shouldn't be a problem to call fstatat() before generating an answer
an invalidate the cache if it returns a different mtime then previously.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Florian Weimer]

On 03/07/2018 01:55 PM, Stephen Gallagher wrote:

Yes, SSSD monitors those files and automatically cleans its cache.

However, you're right. On systems not using SSSD (which I suspect is a
nontrivial number of systems running systemd...), people are probably still
using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
where appropriate) if the nscd service is running.


nscd is supposed to monitor these files, too.

But is this monitoring sufficient?  RPM will immediately start 
installing files after the scriptlet has finished.  nscd and SSSD may 
not have completed their cache invalidation at this point, so this looks 
like a race condition to me.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Stephen Gallagher]

On Wed, Mar 7, 2018 at 5:56 AM Tom Hughes  wrote:

> On 07/03/18 10:46, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Mar 07, 2018 at 10:28:58AM +, Tom Hughes wrote:
> >> On 07/03/18 10:10, Florian Weimer wrote:
> >>> On 03/06/2018 03:24 PM, Zbigniew Jędrzejewski-Szmek wrote:
>  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.
> >>>
> >>> Does it perform any locking or cache invalidation?
> >>
> >> It appears to do locking:
> >>
> >>
> https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1953
> >>
> >> which is calling:
> >>
> >>
> https://github.com/systemd/systemd/blob/master/src/basic/user-util.c#L548
> >>
> >> which takes a write lock on /etc/.pwd.lock around everything.
> > Ack.
> >
> > Cache invalidation? I'm not sure what you mean, it just replaces the
> > file atomically and syncs the file system.
>
> Well historically nscd I guess though I think sssd is supposed to
> have replaced that now?
>
> I believe sssd watches the files with inotify and does it's own
> cache invalidation - a quick test with strace suggests it notices
> when I edit the groups file with vi.
>

Yes, SSSD monitors those files and automatically cleans its cache.

However, you're right. On systems not using SSSD (which I suspect is a
nontrivial number of systems running systemd...), people are probably still
using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
where appropriate) if the nscd service is running.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 07, 2018 at 01:07:15PM +0100, Steve Grubb wrote:
> On Tue, 6 Mar 2018 16:31:29 +
> Zbigniew Jędrzejewski-Szmek  wrote:
> 
> > > > > > 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?  
> > > 
> > > Yes. Absolutely. Even if that user is a system account.
> > >   
> > > > We can't necessarily know on every end-user system when a user is
> > > > added by a central authority like FreeIPA, for example.  
> > > 
> > > That also has to be audited.
> > >   
> > > > 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.  
> > > 
> > > True. And we do include rules to catch these occurrences. But this
> > > not the preferred way because it does not give us the full
> > > information that is required. If we know that we are adding user
> > > accounts, we need to maintain the information for the whole
> > > lifecycle. If FreeIPA adds an account, it gets used and trips some
> > > audit events, then gets removed, we need the history of when it was
> > > added and when it was removed and by who.  
> > 
> > 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.)
Cool, thanks!

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Steve Grubb]

On Tue, 6 Mar 2018 16:31:29 +
Zbigniew Jędrzejewski-Szmek  wrote:

> > > > > 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?  
> > 
> > Yes. Absolutely. Even if that user is a system account.
> >   
> > > We can't necessarily know on every end-user system when a user is
> > > added by a central authority like FreeIPA, for example.  
> > 
> > That also has to be audited.
> >   
> > > 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.  
> > 
> > True. And we do include rules to catch these occurrences. But this
> > not the preferred way because it does not give us the full
> > information that is required. If we know that we are adding user
> > accounts, we need to maintain the information for the whole
> > lifecycle. If FreeIPA adds an account, it gets used and trips some
> > audit events, then gets removed, we need the history of when it was
> > added and when it was removed and by who.  
> 
> 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.)

Thanks,
-Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Tom Hughes]

On 07/03/18 10:46, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Mar 07, 2018 at 10:28:58AM +, Tom Hughes wrote:

On 07/03/18 10:10, Florian Weimer wrote:

On 03/06/2018 03:24 PM, Zbigniew Jędrzejewski-Szmek wrote:

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.


Does it perform any locking or cache invalidation?


It appears to do locking:

https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1953

which is calling:

https://github.com/systemd/systemd/blob/master/src/basic/user-util.c#L548

which takes a write lock on /etc/.pwd.lock around everything.

Ack.

Cache invalidation? I'm not sure what you mean, it just replaces the
file atomically and syncs the file system.


Well historically nscd I guess though I think sssd is supposed to
have replaced that now?

I believe sssd watches the files with inotify and does it's own
cache invalidation - a quick test with strace suggests it notices
when I edit the groups file with vi.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 07, 2018 at 10:28:58AM +, Tom Hughes wrote:
> On 07/03/18 10:10, Florian Weimer wrote:
> >On 03/06/2018 03:24 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >>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.
> >
> >Does it perform any locking or cache invalidation?
> 
> It appears to do locking:
> 
> https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1953
> 
> which is calling:
> 
> https://github.com/systemd/systemd/blob/master/src/basic/user-util.c#L548
> 
> which takes a write lock on /etc/.pwd.lock around everything.
Ack.

Cache invalidation? I'm not sure what you mean, it just replaces the
file atomically and syncs the file system.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Tom Hughes]

On 07/03/18 10:10, Florian Weimer wrote:

On 03/06/2018 03:24 PM, Zbigniew Jędrzejewski-Szmek wrote:

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.


Does it perform any locking or cache invalidation?


It appears to do locking:

https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1953

which is calling:

https://github.com/systemd/systemd/blob/master/src/basic/user-util.c#L548

which takes a write lock on /etc/.pwd.lock around everything.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Florian Weimer]

On 03/06/2018 03:24 PM, Zbigniew Jędrzejewski-Szmek wrote:

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.


Does it perform any locking or cache invalidation?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 06, 2018 at 05:15:45PM +0100, Steve Grubb wrote:
> On Tue, 06 Mar 2018 14:34:58 +
> Stephen Gallagher  wrote:
> 
> > 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 +
> > > > Zbigniew Jędrzejewski-Szmek  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?
> 
> Yes. Absolutely. Even if that user is a system account.
> 
> > We can't necessarily know on every end-user system when a user is
> > added by a central authority like FreeIPA, for example.
> 
> That also has to be audited.
> 
> > 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.
> 
> True. And we do include rules to catch these occurrences. But this not
> the preferred way because it does not give us the full information
> that is required. If we know that we are adding user accounts, we need
> to maintain the information for the whole lifecycle. If FreeIPA adds an
> account, it gets used and trips some audit events, then gets removed,
> we need the history of when it was added and when it was removed and
> by who.

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.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Steve Grubb]

On Tue, 6 Mar 2018 14:24:27 +
Zbigniew Jędrzejewski-Szmek  wrote:

> On Tue, Mar 06, 2018 at 01:03:30PM +0100, Steve Grubb wrote:
> > On Mon, 5 Mar 2018 23:11:12 +
> > Zbigniew Jędrzejewski-Szmek  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.

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Steve Grubb]

On Tue, 06 Mar 2018 14:34:58 +
Stephen Gallagher  wrote:

> 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 +
> > > Zbigniew Jędrzejewski-Szmek  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?

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

> We can't necessarily know on every end-user system when a user is
> added by a central authority like FreeIPA, for example.

That also has to be audited.

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

True. And we do include rules to catch these occurrences. But this not
the preferred way because it does not give us the full information
that is required. If we know that we are adding user accounts, we need
to maintain the information for the whole lifecycle. If FreeIPA adds an
account, it gets used and trips some audit events, then gets removed,
we need the history of when it was added and when it was removed and
by who.

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

Not really, it gives us information about account creation or removal
and who did it. This may be normal or an anomaly.

> whether a user is *available* is not interesting in comparison to when that
> user logs in.

That is also interesting as are a lot of things. But if we are creating
accounts then we need the whole lifecycle recorded.

-Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Stephen Gallagher]

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 +
> > Zbigniew Jędrzejewski-Szmek  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

Re: systemd 238 and sysusers

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 06, 2018 at 01:03:30PM +0100, Steve Grubb wrote:
> On Mon, 5 Mar 2018 23:11:12 +
> Zbigniew Jędrzejewski-Szmek  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.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Steve Grubb]

On Mon, 5 Mar 2018 23:11:12 +
Zbigniew Jędrzejewski-Szmek  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?

Thanks,
-Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Stephen Gallagher]

On Mon, Mar 5, 2018 at 6:28 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Mon, Mar 05, 2018 at 05:16:36PM -0600, Jason L Tibbitts III wrote:
> > > "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
> >
> > ZJ> - various transfiletriggers have been ported from Mageia, for the
> > ZJ>   udev hwdb and rules, the journal catalog, sysctl.d, binfmt.d,
> > ZJ>   sysusers.d, and tmpfiles.d. This means that for many packages,
> > ZJ>   which do not need those rules to be applied immediately,
> > ZJ>   scriptlets can be totally removed.
> >
> > So, could you possibly give the packaging committee a heads up as soon
> > as possible?  Preferably like a few days ago?
> >
> > ZJ> - somewhat independently, systemd-sysusers has been beefed up so it
> > ZJ>   is possible to use it to create system users before any files are
> > ZJ>   installed on disk, but honouring admin overrides. In short, we now
> > ZJ>   recommend the following invocation to create users for an rpm
> > ZJ>   which contains files owned by those users:
> >
> > ZJ> %sysusers_create_package %{name} %SOURCEN
> >
> > But the packaging guidelines _don't_ recommend that.  And they won't
> > until someone gives us a heads up.  Please don't ask folks to change
> > their packages before you've even given the packaging committee a chance
> > to change the guidelines.
>
> Hi,
>
> I was speaking with my upstream hat on, not trying to suggest
> immediate changes to packaging in Fedora. I'm aware the guidelines
> recommend getent/useradd calls right now. There are some idea to change
> this, but my mail wasn't supposed to start that process. I hope this
> will be discussed for F29, in due time.
>
> Sorry, I should have written this like "If you were to use
> systemd-sysusers to create users for an rpm, we would recommend ...".
>
> Zbyszek



Sorry about that, Tibbs. I’ve got it on my TODO list to put together a
guidelines proposal this week. To all reading: this is *not* yet the
recommended approach and will not be until and unless FPC approves new
guidelines.

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 05, 2018 at 05:16:36PM -0600, Jason L Tibbitts III wrote:
> > "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
> 
> ZJ> - various transfiletriggers have been ported from Mageia, for the
> ZJ>   udev hwdb and rules, the journal catalog, sysctl.d, binfmt.d,
> ZJ>   sysusers.d, and tmpfiles.d. This means that for many packages,
> ZJ>   which do not need those rules to be applied immediately,
> ZJ>   scriptlets can be totally removed.
> 
> So, could you possibly give the packaging committee a heads up as soon
> as possible?  Preferably like a few days ago?
> 
> ZJ> - somewhat independently, systemd-sysusers has been beefed up so it
> ZJ>   is possible to use it to create system users before any files are
> ZJ>   installed on disk, but honouring admin overrides. In short, we now
> ZJ>   recommend the following invocation to create users for an rpm
> ZJ>   which contains files owned by those users:
> 
> ZJ> %sysusers_create_package %{name} %SOURCEN
> 
> But the packaging guidelines _don't_ recommend that.  And they won't
> until someone gives us a heads up.  Please don't ask folks to change
> their packages before you've even given the packaging committee a chance
> to change the guidelines.

Hi,

I was speaking with my upstream hat on, not trying to suggest
immediate changes to packaging in Fedora. I'm aware the guidelines
recommend getent/useradd calls right now. There are some idea to change
this, but my mail wasn't supposed to start that process. I hope this
will be discussed for F29, in due time.

Sorry, I should have written this like "If you were to use
systemd-sysusers to create users for an rpm, we would recommend ...".

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Jason L Tibbitts III]

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> - various transfiletriggers have been ported from Mageia, for the
ZJ>   udev hwdb and rules, the journal catalog, sysctl.d, binfmt.d,
ZJ>   sysusers.d, and tmpfiles.d. This means that for many packages,
ZJ>   which do not need those rules to be applied immediately,
ZJ>   scriptlets can be totally removed.

So, could you possibly give the packaging committee a heads up as soon
as possible?  Preferably like a few days ago?

ZJ> - somewhat independently, systemd-sysusers has been beefed up so it
ZJ>   is possible to use it to create system users before any files are
ZJ>   installed on disk, but honouring admin overrides. In short, we now
ZJ>   recommend the following invocation to create users for an rpm
ZJ>   which contains files owned by those users:

ZJ> %sysusers_create_package %{name} %SOURCEN

But the packaging guidelines _don't_ recommend that.  And they won't
until someone gives us a heads up.  Please don't ask folks to change
their packages before you've even given the packaging committee a chance
to change the guidelines.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org