Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 89122

Summary: getpwnam in static executables segfaults if "compat" is listed for passwd in /etc/nsswitch.conf
Product: [Retired] Red Hat Linux Reporter: Kees Cook <kees>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 8.0CC: fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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: --- Target Upstream Version:
Embargoed:
Bug Depends On: 59709    
Bug Blocks:    
Attachments:
Description Flags
Output from gdb
none
Minimal example code none

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.