Bug 169725 - udev requires network access for ldap
Summary: udev requires network access for ldap
Alias: None
Product: Fedora
Classification: Fedora
Component: udev   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
: 176605 176836 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-10-02 08:02 UTC by Ola Thoresen
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-16 10:31:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ola Thoresen 2005-10-02 08:02:13 UTC
Description of problem:
It seems like udev might need network access if nsswitch is set up with
authentication from ldap:

passwd:     files ldap
shadow:     files ldap
group:      files ldap

This leads to the following errors:

Sep 19 15:48:36 ws21 udevstart[2042]: nss_ldap: reconnecting to LDAP
server (sleeping 4 seconds)...
Sep 19 15:48:40 ws21 udevstart[2042]: nss_ldap: reconnecting to LDAP
server (sleeping 8 seconds)...

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

How reproducible:

Steps to Reproduce:
1. configure ldap authentication
2. reboot
Actual results:
start_udev hangs, and exits with an error.
udev is not available, making all sorts of bad things happen...

Expected results:
udev should start fine even before the network is up

Additional info:
Harald Hoyer replied with the following on the fedora-devel list:
"grrr... this seems to be glibc and getpwnam(3)"

I am posting this as a bug in udev, even if that might just be a symptom, but I
am adding jakub@redhat.com to Cc: as glibc-maintainer.

Comment 1 Harald Hoyer 2005-10-05 07:23:14 UTC
This is getgrnam(3) and getpwnam(3).
Jakub, how can I prevent this to happen, if there is no network access?

Comment 2 Jakub Jelinek 2005-10-05 07:47:18 UTC
glibc honors whatever you state in nsswitch.conf.
This bug report doesn't go into detail what exact users/groups have been looked
up and whether they exist in /etc/passwd resp. /etc/group or just in ldap.
With the order files ldap in nsswitch.conf ldap ought to be used only if
the user/group hasn't been found in the local files (just tested that
to make sure and it works that way).
The way to prevent ldap from being accessed is to edit nsswitch.conf.

But, if the user resp. group udev is trying to look up only exist in ldap,
you are screwed up anyway.  Even if you edited nsswitch.conf to exclude all
networking nss modules (say e.g. mount --bind'ed it for the process or
something), if the user/group is not present locally, udev will never be able
to find it out.

Comment 3 Harald Hoyer 2005-10-05 08:10:24 UTC
Ola Thoresen, did you add any custom udev rules?

Comment 4 Ola Thoresen 2005-10-05 08:39:03 UTC
No, I have not added any custom rules.

But could this be the reason?

KERNEL=="usb/dabusb*",            GROUP="usb", MODE="0660"
KERNEL=="usb/mdc800*",            GROUP="usb", MODE="0660"
KERNEL=="usb/rio500",             GROUP="usb", MODE="0660"

I don't have any "usb" group in /etc/group, so it might be that group it is
trying to resolve?
All other groups mentioned in rules.d/* are in /etc/group

Now, I can't find any of these devices in /dev, and the modules are not loaded,
but it is the only thing that I can think of that might cause it to connect to
the ldap-server.
But I am in no way an udev expert, so it might be something completely different.
I'll try to remove these rules (or add the group "usb", whatever you think is
the correct solution) and see if that makes a difference.

Comment 5 Ola Thoresen 2005-10-10 08:20:13 UTC
It is the missing group "usb" that causes the problem.
Commenting out those three lines wil allow udev to start at boot again.

When was this group added, and by what package?

Comment 6 Harald Hoyer 2005-10-10 09:48:00 UTC
yes, group USB is wrong, sry... removed..

Comment 7 Jarod Wilson 2006-01-03 08:31:27 UTC
This one's back. Looks like its probably being triggered by this line in

SUBSYSTEM=="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", GROUP="video"

...since there's no video group. And that's a positive confirmation, just
rebooted after adding a video group, no more udev complaints about nss_ldap.

Comment 8 Harald Hoyer 2006-01-11 09:45:14 UTC
*** Bug 176836 has been marked as a duplicate of this bug. ***

Comment 9 Harald Hoyer 2006-01-11 09:45:24 UTC
*** Bug 176605 has been marked as a duplicate of this bug. ***

Comment 10 Harald Hoyer 2006-01-11 12:31:24 UTC
should be fixed again with udev-078-4

Comment 11 W. Michael Petullo 2006-01-13 14:31:45 UTC
Seems fixed in udev-078-4.

Comment 12 Pawel Salek 2006-02-14 10:37:37 UTC
This problem is present again in udev-084. I have no custom groups added.

Comment 13 Harald Hoyer 2006-02-14 10:48:42 UTC
This may be bug #181432 .

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