Bug 89122 - getpwnam in static executables segfaults if "compat" is listed for passwd in /etc/nsswitch.conf
Summary: getpwnam in static executables segfaults if "compat" is listed for passwd in ...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 8.0
Hardware: All Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On: 59709
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-17 20:47 UTC by Kees Cook
Modified: 2016-11-24 14:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-23 07:37:16 UTC
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 20:48 UTC, Kees Cook
no flags Details
Minimal example code (1.36 KB, text/plain)
2003-04-17 20:49 UTC, Kees Cook
no flags Details

Description Kees Cook 2003-04-17 20:47:06 UTC
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 20:48:20 UTC
Created attachment 91179 [details]
Output from gdb

Comment 2 Kees Cook 2003-04-17 20:49:15 UTC
Created attachment 91180 [details]
Minimal example code

Comment 3 Ulrich Drepper 2003-04-22 08:52:54 UTC
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 16:23:09 UTC
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 07:37:16 UTC
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.