Bug 466794 - useradd -r loops when talking to ldap server
Summary: useradd -r loops when talking to ldap server
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: shadow-utils
Version: 9
Hardware: All
OS: Linux
medium
urgent
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-13 16:56 UTC by Anders Blomdell
Modified: 2009-07-14 17:15 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 511813 (view as bug list)
Environment:
Last Closed: 2009-07-14 17:15:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
don't call getpwent after first NULL is returned (906 bytes, patch)
2008-10-13 16:56 UTC, Anders Blomdell
no flags Details | Diff

Description Anders Blomdell 2008-10-13 16:56:00 UTC
Created attachment 320205 [details]
don't call getpwent after first NULL is returned 

Description of problem:

When trying to do a 'useradd -r ...' and nsswitch.conf contains 'passwd: files ldap',
the command hangs in an infinite loop.

Version-Release number of selected component (if applicable):

shadow-utils-4.1.1-4.fc9.i386



How reproducible:

Always

Steps to Reproduce:
1. useradd -r -s /some/shell -d /some/dir -M -g some_group some_user

  
Actual results:

Infinite loop

Expected results:

User added

Additional info:

The reason seems to be that getpwent() returns NULL once, and then restarts delivery of results from the LDAP database.

Comment 1 Anders Blomdell 2008-10-13 17:27:54 UTC
Actually, it doesn't enter an infinite loop. It only loops through the LDAP database once for each entry in the local password database, due to the fact that in the following loop the first time getpwent returns NULL, pw_next returns the first local entry, then on the next iteration getpwent restarts reading the LDAP database.

       while (   ((pwd = getpwent ()) != NULL)
              || ((pwd = pw_next ()) != NULL)) {


but with 30 machines trying to add the same user, a local passwd with 50 users and a LDAP database with 12000 users, it all boiled down to 30 * 50 * 12000 = 18000000 LDAP lookups, which takes a very long time.

Comment 2 Anders Blomdell 2008-10-14 12:30:15 UTC
Filed bug against upstream libnss_ldap as well:

http://bugzilla.padl.com/show_bug.cgi?id=376

Comment 3 lexual 2009-03-04 00:12:33 UTC
Upstream bug has been closed.
Is this still an issue for the reporter?

Comment 4 Bug Zapper 2009-06-10 02:57:10 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 stef 2009-06-16 15:31:13 UTC
I can see the same trouble with FC11 final.

Trying to install the akmods package from RpmFusion, the package sits forever and does not install.

I could look into the package seeing it was blocked at the %pre step :

useradd -r -g akmods -d /var/cache/akmods/ -s /sbin/nologin -c 'User is used by akmods to build akmod packages' akmods


I also have a Ldap server for authentication.

Comment 6 stef 2009-06-18 09:59:02 UTC
this can be seen too when trying to install the package "partimage-server"

the following is involved :

D:   install: %pre(partimage-server-0.6.7-7.fc11.i586)	execv(/bin/sh) pid 21938
+ /usr/sbin/useradd -M -r -s /sbin/nologin -d /var/partimaged -c 'Partition imaging utility' partimag

Comment 7 stef 2009-06-29 11:49:41 UTC
I got additional infos,

using strace I have 'listened' to what happens to the useradd command and it showed me this :

# strace useradd -r -g akmods -d /var/cache/akmods/ -s /sbin/nologin -c 'User is used by akmods to build akmod packages' akmods

then we can see that useradd tries to browse THE WHOLE ldap directory

*extract*

rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 201210}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\214\2\1\3d"..., 8)     = 8
read(4, "\202\1\205\4%uid=anedroum,ou=User,dc=devi"..., 392) = 392
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 201877}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\210\2\1\3d"..., 8)     = 8
read(4, "\202\1\201\4$uid=abaghor,ou=User,dc=devin"..., 388) = 388
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 202563}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\204\2\1\3d"..., 8)     = 8
read(4, "\202\1}\4#uid=bbalan,ou=User,dc=devinc"..., 384) = 384
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 203231}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\214\2\1\3d"..., 8)     = 8
read(4, "\202\1\205\4%uid=hbouichm,ou=User,dc=devi"..., 392) = 392
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 203883}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\214\2\1\3d"..., 8)     = 8
read(4, "\202\1\205\4%uid=hbounekt,ou=User,dc=devi"..., 392) = 392
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 204537}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\214\2\1\3d"..., 8)     = 8
read(4, "\202\1\205\4%uid=lcouliba,ou=User,dc=devi"..., 392) = 392
time(NULL)                              = 1246276038
rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0
gettimeofday({1246276038, 205199}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "0\202\1\210\2\1\3d"..., 8)     = 8
read(4, "\202\1\201\4$uid=scourty,ou=User,dc=devin"..., 388) = 388
time(NULL)                              = 1246276038

*extract*

of course doing so can be very long... 

this behaviour should be fixed

Comment 8 stef 2009-06-29 11:52:30 UTC
as a reminder, the problem I describe in comment #5 #6 #7 are in Fedora Core 11

So this is an ACTUAL problem, not a end-of-life distro.

This bug should be re-qualified as actual too

Comment 9 stef 2009-06-29 11:53:14 UTC
since relevant infos are provided

Comment 10 Peter Vrabec 2009-06-30 09:11:32 UTC
loop mentioned in comment #1 is not present in shadow-utils >= F11.

Q. is what you want to  fix. useradd has to iterate thru LDAP. 
man page:
"You may not add a user to a NIS or LDAP group. This must be performed on the corresponding server.
Similarly, if the username already exists in an external user database such as NIS or LDAP, useradd will deny the user account creation request."

Comment 11 stef 2009-06-30 09:25:25 UTC
(In reply to comment #10)

I don't get your question, if it is one.

So to you it is perfectly normal that you have to wait for several minutes for a simple "useradd", or a RPM installation that creates a user account in its 'pre' commands ?

for the record, our LDAP server only has accounts with UID number over 5 digits to not mix with 3 digits system ones.
So logicaly it should find very fast an available UID number right after looking into /etc/password, not spending aeons to browse a identification server with very high,therefore not interesting, numbers.

Comment 12 Peter Vrabec 2009-07-01 09:44:33 UTC
Unfortunately, it's not that easy, because:

1. getpwent() doesn't return entries in chronology 
example:
UID: 1 4 3 100

2. in case of user accounts it's always looking for for max first unused values
example:
UIDs: 1 4 3 100 -> 101 is the one

But there is a possibility to change alg. a bit. in a way that  getpwuid() is used for system accounts. Let me ask upstream what they think about it. This could solve the problem at least for system accounts. :)

Comment 13 Bug Zapper 2009-07-14 17:15:06 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.