732805 – getpwnam does not work on 64-bit RHEL6.1 when built with -m32

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

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
Sub Component:
Version:	6.2
Hardware:	x86_64
OS:	Linux
Priority:	unspecified
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Andreas Schwab
QA Contact:	qe-baseos-tools-bugs
Docs Contact:
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)
CC List:	2 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2011-08-31 06:08:14 UTC
Target Upstream Version:
Embargoed:

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 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.