Bug 181432 - vol_id fails to drop privileges
Summary: vol_id fails to drop privileges
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
URL:
Whiteboard:
: 182700 (view as bug list)
Depends On:
Blocks: 181306
TreeView+ depends on / blocked
 
Reported: 2006-02-13 22:43 UTC by Nalin Dahyabhai
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-27 13:08:41 UTC


Attachments (Terms of Use)
patch to use "nobody"'s primary group instead of assuming that it's named "nogroup" and going from there (2.67 KB, patch)
2006-02-13 22:43 UTC, Nalin Dahyabhai
no flags Details | Diff

Description Nalin Dahyabhai 2006-02-13 22:43:38 UTC
Description of problem:
vol_id attemps to drop privileges to that of the 'nobody' user when it runs, by
switching to the 'nogroup' gid and the 'nobody' uid.  This fails on Fedora
because we don't have a 'nogroup' group.  (It also creates boot delays when
network-using nsswitch modules are in use, but that's a side-effect.)

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

How reproducible:
Always

Steps to Reproduce:
1. Switch on "ldap" for use in "group" lookups in /etc/nsswitch.conf, preferably
with a default /etc/ldap.conf on the system.
2. Reboot.
  
Actual results:
Debug spew as vol_id tries to look up information about the group.

Expected results:
Quick bootup.

Additional info:
Why not just use the user's primary group ID?

Comment 1 Nalin Dahyabhai 2006-02-13 22:43:38 UTC
Created attachment 124586 [details]
patch to use "nobody"'s primary group instead of assuming that it's named "nogroup" and going from there

Comment 2 Harald Hoyer 2006-02-14 07:19:36 UTC
Very good suggestion! Thank you for the patch! :)

Comment 3 Gordon Messmer 2006-02-24 05:06:32 UTC
*** Bug 182700 has been marked as a duplicate of this bug. ***

Comment 4 Andreas Bierfert 2006-02-24 15:44:48 UTC
ping

will this hit rawhide anytime soon or is there a test rpm somewhere?

Comment 5 Harald Hoyer 2006-02-24 15:55:51 UTC
already should have with udev-084-4

Comment 6 Ignacio Vazquez-Abrams 2006-02-24 16:39:55 UTC
So in other words you're saying that something completely different is causing
boot issues with udev and LDAP? How do we debug this?

Comment 7 Andreas Bierfert 2006-02-24 17:07:11 UTC
Hm ok... the vol_id error went away here with current udev release but now there
are lots of other errors... Could this by any chance be
related/affected/affecting bug #181305?

Comment 8 Andreas Bierfert 2006-02-26 08:41:45 UTC
With latest udev 084-6 everyting is working. This bug can be closed imho. Thanks.


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