Re: systemd 238 and sysusers
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> "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