Bug 732805 - getpwnam does not work on 64-bit RHEL6.1 when built with -m32
Summary: getpwnam does not work on 64-bit RHEL6.1 when built with -m32
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc
Version: 6.2
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Andreas Schwab
QA Contact: qe-baseos-tools
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-23 16:58 UTC by Allen Zhao
Modified: 2016-11-24 16:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-31 06:08:14 UTC


Attachments (Terms of Use)

Description Allen Zhao 2011-08-23 16:58:17 UTC
Description of problem:
getpwnam does not return good value on 64-bit RHEL6.1 when built with -m32.

Version-Release number of selected component (if applicable):
both 6.0 and 6.1 have this issue. The issue does not exist for earlier RHEL4/5.

How reproducible:
always.


Steps to Reproduce:
1. source code (save it as testget.cpp)
#include <sys/types.h>
#include <pwd.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

main()
{

char *lgn;
struct passwd *pw;
if ((lgn = getlogin()) == NULL || (pw = getpwnam("cluster")) == NULL) {
    fprintf(stderr, "Get of user information failed.\n"); exit(1);
}

 printf("\nThe user name is: %s\n", pw->pw_name);
     printf("The user id   is: %u\n", pw->pw_uid);
     printf("The group id  is: %u\n", pw->pw_gid);
     printf("The initial directory is:    %s\n", pw->pw_dir);
     printf("The initial user program is: %s\n", pw->pw_shell);

}

2. do `g++ -m32 testget.cpp -o testget32` on a RHEL6.x/x64 machine

3. run testget32
  
Actual results:
[root@beethoven ~]# ~petr/tcpp/testget32
Get of user information failed.


Expected results:
[root@beethoven ~]# ~petr/tcpp/testget64

The user name is: cluster
The user id   is: 8579
The group id  is: 10
The initial directory is:    /User/cluster
The initial user program is: /bin/bash


Additional info:
Removing -m32 (building 64-bit native app), the problem is gone.

Comment 2 RHEL Product and Program Management 2011-08-23 17:28:17 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 3 Allen Zhao 2011-08-24 16:38:50 UTC
Then can this be addressed in 6.2 release?

Comment 4 Andreas Schwab 2011-08-30 07:56:42 UTC
Make sure you have all configured NSS modules installed.

Comment 5 Allen Zhao 2011-08-30 13:46:43 UTC
Hi, Andreas,

How do you check my NSS modules? `rpm -qa`? Let me know. 

From commandline:
[root@gershwin ~]# getent passwd allen
allen:*:1004:301:Allen Zhao:/User/allen:/bin/bash

Our box is integrated with a Windows server with LDAP/Kerberos5. Above shows the LDAP user info is ok. Of course, the getent must be 64-bit here. `kinit` also works ok. So I do not see a NSS issue here.

If this is indeed NSS module installation issue, well, the only thing I know is that we selected workstation during installation, nothing was disabled. I know this probably does not answer your question, but it is just a background info.

Also, if it is indeed NSS modules, when the same code compiled in 64-bit mode works, but compiled in 32-bit mode (-m32) simply fail?

Comment 6 Andreas Schwab 2011-08-30 14:18:45 UTC
See /etc/nsswitch.conf.

Comment 7 Allen Zhao 2011-08-30 14:33:36 UTC
we used sss:
related entries in /etc/nsswitch.conf
passwd:     files sss
shadow:     files sss
group:      files sss

the /etc/sssd/sssd.conf entries:

services = nss, pam
domains = default

[domain/default]
id_provider = ldap
ldap_uri = ldap://xxxx.gtisoft.com,ldap://yyyy.gtisoft.com
ldap_search_base = dc=gtisoft,dc=com
ldap_default_bind_dn = cn=ldapadmin,cn=Users,dc=gtisoft,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = whatever

auth_provider = krb5
chpass_provider = krb5
krb5_kpasswd = xxxx.gtisoft.com,yyyy.gtisoft.com
krb5_server = xxxx.gtisoft.com,yyyy.gtisoft.com
krb5_realm = GTISOFT.COM
krb5_kdcip = xxxx.gtisoft.com,yyyy.gtisoft.com
cache_credentials = True

ldap_user_object_class = person
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_principal = userPrincipalName
ldap_user_home_directory = unixHomeDirectory
ldap_user_name = sAMAccountName

ldap_group_object_class = group
ldap_group_name = sAMAccountName
ldap_group_gid_number = gidNumber

ldap_force_upper_case_realm = True
ldap_id_use_start_tls = False
ldap_tls_cacertdir = /etc/openldap/cacerts

As I just asked in previous reply, if commandline `getent passwd allen` works fine, what else could be missing? We have no user login issue, it is only when we compile the code snip with '-m32', things fall apart. 

Can you reproduce the issue in your system? (with -m32 compiler option).

Comment 8 Andreas Schwab 2011-08-30 14:42:27 UTC
Make sure /lib/libnss_sss.so.* is installed.

Comment 9 Allen Zhao 2011-08-30 14:51:43 UTC
I do not see /lib/libnss_sss.so.* at all.

All I have (as part of the default system installation):
[root@gershwin ~]# ls -al /lib/libnss_
libnss_compat-2.12.so   libnss_files-2.12.so    libnss_nis-2.12.so
libnss_compat.so.2      libnss_files.so.2       libnss_nisplus-2.12.so
libnss_dns-2.12.so      libnss_hesiod-2.12.so   libnss_nisplus.so.2
libnss_dns.so.2         libnss_hesiod.so.2      libnss_nis.so.2

which rpm has this file? I have checked that RHEL6.0 and RHEL6.1 installation both have 32-bit libnss_sss.so.* missing. On the other hand, the /lib64/libnss_sss.so.2 does exist.

So, this is a system installation issue?

Comment 10 Allen Zhao 2011-08-30 15:17:45 UTC
I just checked my RHEL6.1 DVD, sssd-client-1.5.1-34.el6.i686.rpm is there. But the dependency on 32-bit PAM subsystem is a lot of work.

[root@gershwin Packages]# rpm -i sssd-client-1.5.1-34.el6.i686.rpm
warning: sssd-client-1.5.1-34.el6.i686.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
error: Failed dependencies:
        libpam.so.0 is needed by sssd-client-1.5.1-34.el6.i686
        libpam.so.0(LIBPAM_1.0) is needed by sssd-client-1.5.1-34.el6.i686
        libpam.so.0(LIBPAM_EXTENSION_1.0) is needed by sssd-client-1.5.1-34.el6.i686
        libpam.so.0(LIBPAM_MODUTIL_1.0) is needed by sssd-client-1.5.1-34.el6.i686


[root@gershwin Packages]# rpm -i pam-1.1.1-8.el6.i686.rpm
warning: pam-1.1.1-8.el6.i686.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
error: Failed dependencies:
        libaudit.so.1 is needed by pam-1.1.1-8.el6.i686
        libcrack.so.2 is needed by pam-1.1.1-8.el6.i686
        libdb-4.7.so is needed by pam-1.1.1-8.el6.i686
        libselinux.so.1 is needed by pam-1.1.1-8.el6.i686

Is there a reason why RH does not make the 32-bit PAM/SSSD part of the default installation? This is a really bad installation, comparing with the current SLES 11.x installation. 

I guess you can close this bug. I do feel that a bug should be logged in the RHEL installer to resolve this. We are shipping some 32-bit daemons to our customers for the foreseeable future. If we have to let customers to go through all these troubles (actually we already have enough trouble with RHEL6.x for removing some crucial 32-bit C++ runtimes), it is very very bad.

Comment 11 Andreas Schwab 2011-08-31 06:08:14 UTC
yum install sssd-client.i686


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