Bug 89122 - getpwnam in static executables segfaults if "compat" is listed for passwd in /etc/nsswitch.conf
getpwnam in static executables segfaults if "compat" is listed for passwd in ...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
8.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On: 59709
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-17 16:47 EDT by Kees Cook
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-23 03:37:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from gdb (1.99 KB, text/plain)
2003-04-17 16:48 EDT, Kees Cook
no flags Details
Minimal example code (1.36 KB, text/plain)
2003-04-17 16:49 EDT, Kees Cook
no flags Details

  None (edit)
Description Kees Cook 2003-04-17 16:47:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030319
Debian/1.3-3

Description of problem:
static binaries (like, say "rpm") will segfault on calls to getpwnam if "compat"
is listed in "passwd" line on /etc/nsswitch.conf, and you have an NIS keyword in
/etc/passwd (+@netgroup).  This does not happen for dynamic-link binaries,
strangely.

I imagine it's the magic used to dlopen the libnss_compat library into a static
binary's execution space, but gdb lost its mind when I tried to trace through
the calls.


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

How reproducible:
Always

Steps to Reproduce:
1. Add "+@bogus" to the end of /etc/passwd
2. Make sure "compat" is listed on the "passwd:" line of /etc/nsswitch.conf
3. Make an static binary with a call to "getpwnam" in it.
4. Run the binary. (or use "rpm" to install a src rpm)


Actual Results:  # ./getpwnam.static rusty
Segmentation fault


Expected Results:  # ./getpwnam rusty       
No such user 'rusty'


Additional info:

If you "step" though it with gdb, you can see the execution about as far as the
calls in glibc's nss/getXXbyYY_r.c, but after the DL_CALL_FCT gdb loses it's
mind.  It does, however, appear to end up in the nis/nss_compat/compat-pwd.c
getpwnam_r function.
Comment 1 Kees Cook 2003-04-17 16:48:20 EDT
Created attachment 91179 [details]
Output from gdb
Comment 2 Kees Cook 2003-04-17 16:49:15 EDT
Created attachment 91180 [details]
Minimal example code
Comment 3 Ulrich Drepper 2003-04-22 04:52:54 EDT
I very much doubt that I'll fix that.  NSS in statically linked apps is only
minimally supported, only simple services.  In fact, static linking should be
avoided for almost any cost, it's evil and will always have problems. 
Statically linked binaries are much less stable after runtime upgrades.

I'll look at the code but better get rid of either static linking or this NIS hack.
Comment 4 Kees Cook 2003-04-22 12:23:09 EDT
Well, it's pretty confusing to have "rpm" segfault.  On the machines we
kickstart, we can't have our NIS running until all the RPMs are installed.  Do
glibc 2.3.x's nss_compat libraries seg fault?
Comment 5 Ulrich Drepper 2003-04-23 03:37:16 EDT
Sure you can use rpm.  rpm is dynamically linked in RHL9.

As I said, I'll look briefly at it.  If I cannot reproduce it or it turns out to
be more complicated than a tiny little change it'll not be fixed.  Static
linking is bad.  NIS is horrible.  Combinbed it's a desaster.

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