doveadm user '*' vs sssd: enumeration works only once
Hi,
I've a quite simple setup using sssd (id_provider, auth_provider: AD), and dovecot.
doveadm user *returns the full user list only once. A 2nd invocation of the same command within a small timeframe returns a subset of the local users only (the users I've in /etc/passwd with uid >= first_valid_uid).
If I wait until the dovecot/auth worker processes are gone (or if I kill them), I get the full list again.
Calling
getent passwdrepeateadly always returns the full list of users.
Question:
- [ ] unfortunate configuration (see attachment)
- [ ] misbehaviour of sssd (more specifically its nss module)
- [ ] misbehaviour of dovecot/auth processes?
Dovecot: 2.3.4.1 (f79e8e7e4) Operating System: Debian GNU/Linux 10 (buster) Sssd: 1.16.30
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE -
Heiko Schlittermann <hs@schlittermann.de> (Do 25 Feb 2021 10:08:05 CET):
doveadm user *returns the full user list only once. A 2nd invocation of the same command within a small timeframe returns a subset of the local users only (the
The following Perl script can reproduce the behaviour:
#!/usr/bin/perl
use strict;
use warnings;
use feature 'say';
sub count {
my $n;
setpwent() or die("setpwent");
$n++ while getpwent();
# endpwent();
return $n;
}
say count();
say count();If I miss the endpwent(), the first count retuns 400+ users, but the second one only about 30 (which matches the lines I've in the /etc/passwd file).
If I use the endpwent(), I always get 400+ users.
Su, I suspect, the unfortunate behaviour is on the dovecot side (in the auth processes)
What do you think?
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE -
Heiko Schlittermann <hs@schlittermann.de> (Do 25 Feb 2021 10:36:21 CET):
within a small timeframe returns a subset of the local users only (the say count(); I suppose the following would fix the issue: (not tested yet)
diff --git a/src/auth/userdb-passwd.c b/src/auth/userdb-passwd.c index 70b9969f6..4682dc873 100644 --- a/src/auth/userdb-passwd.c +++ b/src/auth/userdb-passwd.c @@ -208,6 +208,7 @@ static int passwd_iterate_deinit(struct userdb_iterate_context *_ctx) cur_userdb_iter_to = timeout_add(0, passwd_iterate_next_timeout, NULL); } + endpwent(); return ret; } -- Heiko
On 25/02/2021 11:41 Heiko Schlittermann <hs@schlittermann.de> wrote:
Heiko Schlittermann <hs@schlittermann.de> (Do 25 Feb 2021 10:36:21 CET):
within a small timeframe returns a subset of the local users only (the say count(); I suppose the following would fix the issue: (not tested yet)
diff --git a/src/auth/userdb-passwd.c b/src/auth/userdb-passwd.c index 70b9969f6..4682dc873 100644 --- a/src/auth/userdb-passwd.c +++ b/src/auth/userdb-passwd.c @@ -208,6 +208,7 @@ static int passwd_iterate_deinit(struct userdb_iterate_context *_ctx) cur_userdb_iter_to = timeout_add(0, passwd_iterate_next_timeout, NULL); } + endpwent(); return ret; }
-- Heiko
Hi! We'll look into it, might be that we are missing endpwent() there indeed. Aki
On 25/02/2021 13:06 Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
On 25/02/2021 11:41 Heiko Schlittermann <hs@schlittermann.de> wrote:
Heiko Schlittermann <hs@schlittermann.de> (Do 25 Feb 2021 10:36:21 CET):
within a small timeframe returns a subset of the local users only (the say count(); I suppose the following would fix the issue: (not tested yet)
diff --git a/src/auth/userdb-passwd.c b/src/auth/userdb-passwd.c index 70b9969f6..4682dc873 100644 --- a/src/auth/userdb-passwd.c +++ b/src/auth/userdb-passwd.c @@ -208,6 +208,7 @@ static int passwd_iterate_deinit(struct userdb_iterate_context *_ctx) cur_userdb_iter_to = timeout_add(0, passwd_iterate_next_timeout, NULL); } + endpwent(); return ret; }
-- Heiko
Hi!
We'll look into it, might be that we are missing endpwent() there indeed.
Aki
Tracking as DOP-2284. Aki
Aki Tuomi <aki.tuomi@open-xchange.com> (Do 25 Feb 2021 12:06:43 CET):
diff --git a/src/auth/userdb-passwd.c b/src/auth/userdb-passwd.c index 70b9969f6..4682dc873 100644 --- a/src/auth/userdb-passwd.c +++ b/src/auth/userdb-passwd.c @@ -208,6 +208,7 @@ static int passwd_iterate_deinit(struct userdb_iterate_context *_ctx) cur_userdb_iter_to = timeout_add(0, passwd_iterate_next_timeout, NULL); } + endpwent(); return ret; }
-- Heiko
Hi! We'll look into it, might be that we are missing endpwent() there indeed.
I'm not sure about the semantics of setpwent()/endpwent(), mayb the nss plugin (here sssd) should gracefully handle a missing endwent() if it sees a new setpwent(). But I think, it can't harm to call endpwent() on the dovecot side. I deployed a debian package with the above patch added onto my system, and it seems to work. So, should I file a bug report against dovecot? Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE -
On 25/02/2021 13:17 Heiko Schlittermann <hs@schlittermann.de> wrote:
Aki Tuomi <aki.tuomi@open-xchange.com> (Do 25 Feb 2021 12:06:43 CET):
diff --git a/src/auth/userdb-passwd.c b/src/auth/userdb-passwd.c index 70b9969f6..4682dc873 100644 --- a/src/auth/userdb-passwd.c +++ b/src/auth/userdb-passwd.c @@ -208,6 +208,7 @@ static int passwd_iterate_deinit(struct userdb_iterate_context *_ctx) cur_userdb_iter_to = timeout_add(0, passwd_iterate_next_timeout, NULL); } + endpwent(); return ret; }
-- Heiko
Hi! We'll look into it, might be that we are missing endpwent() there indeed.
I'm not sure about the semantics of setpwent()/endpwent(), mayb the nss plugin (here sssd) should gracefully handle a missing endwent() if it sees a new setpwent(). But I think, it can't harm to call endpwent() on the dovecot side.
I deployed a debian package with the above patch added onto my system, and it seems to work.
So, should I file a bug report against dovecot?
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann
You can consider it being filed. Aki
Aki Tuomi <aki.tuomi@open-xchange.com> (Do 25 Feb 2021 12:21:43 CET):
--- a/src/auth/userdb-passwd.c +++ b/src/auth/userdb-passwd.c @@ -208,6 +208,7 @@ static int passwd_iterate_deinit(struct userdb_iterate_context *_ctx) cur_userdb_iter_to = timeout_add(0, passwd_iterate_next_timeout, NULL); } + endpwent(); return ret; }
You can consider it being filed. Aki
Thanks. I filed it as a bug report to Debian too. -- Heiko
Heiko Schlittermann <hs@schlittermann.de> (Do 25 Feb 2021 12:17:55 CET):
I'm not sure about the semantics of setpwent()/endpwent(), mayb the nss plugin (here sssd) should gracefully handle a missing endwent() if it sees a new setpwent(). But I think, it can't harm to call endpwent() on the dovecot side.
I deployed a debian package with the above patch added onto my system, and it seems to work.
I added a small patch to the sssd nss module, preventivly calling its internal endpwent() function, prior to setpwent(). This way I achive the same result, the user's list ist complete now.
So, IMHO the bottom line is: it's not clear if a successive setpwent() should imply an automatic endpwent() on the nss side.
-- Heiko
participants (2)
-
Aki Tuomi
-
Heiko Schlittermann