Bug 732805
| Summary: | getpwnam does not work on 64-bit RHEL6.1 when built with -m32 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Allen Zhao <a.zhao> |
| Component: | glibc | Assignee: | Andreas Schwab <schwab> |
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-tools-bugs |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | fweimer, mfranc |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-08-31 06:08:14 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: | |||
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. Then can this be addressed in 6.2 release? Make sure you have all configured NSS modules installed. 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? See /etc/nsswitch.conf. 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). Make sure /lib/libnss_sss.so.* is installed. 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? 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.
yum install sssd-client.i686 |
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.