Bug 1877730 - NIS users lookup failure in getpwuid
Summary: NIS users lookup failure in getpwuid
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: glibc
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: glibc team
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-10 10:09 UTC by Aleksandr Sharov
Modified: 2023-07-18 14:30 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-24 09:10:18 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Strace of the app with working libs (171.97 KB, text/plain)
2020-09-10 10:11 UTC, Aleksandr Sharov
no flags Details
Strace of the app with not working libs (130.92 KB, text/plain)
2020-09-10 10:12 UTC, Aleksandr Sharov
no flags Details
Ltrace of the app with not working libs (322.91 KB, text/plain)
2020-09-11 16:02 UTC, Aleksandr Sharov
no flags Details

Description Aleksandr Sharov 2020-09-10 10:09:21 UTC
Description of problem:
With installed latest krb5-libs-1.17-18.el8.x86_64, using Univa Grid Engine (uge formerly know as sge) on rhel8.2 doesn't work.

It works if krb5-libs is downgraded to krb5-libs-1.17-9.el8.x86_64.

Version-Release number of selected component (if applicable):
krb5-libs-1.17-18.el8.x86_64

Additional info:
details in case https://access.redhat.com/support/cases/02747159

Comment 1 Aleksandr Sharov 2020-09-10 10:11:51 UTC
Created attachment 1714404 [details]
Strace of the app with working libs

Comment 2 Aleksandr Sharov 2020-09-10 10:12:24 UTC
Created attachment 1714405 [details]
Strace of the app with not working libs

Comment 6 Aleksandr Sharov 2020-09-11 16:02:50 UTC
Created attachment 1714583 [details]
Ltrace of the app with not working libs

Adding ltrace

Comment 9 Florian Weimer 2020-09-11 20:00:50 UTC
Do we have an in-house reproducer for this issue?

In the non-working case, a non-system version of OpenSSL appears to be loaded:

openat(AT_FDCWD, "/opt/uge/8.6.12/bin/lx-amd64/../../lib/lx-amd64/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3

Is it possible to reproduce the problem with the system OpenSSL version?

krb5-libs-1.17-18.el8.x86_64 loads libcrypto.so.1.1 from OpenSSL, while krb5-libs-1.17-9.el8.x86_64 does not. This explains why a downgrade krb5-libs appears to resolve the issue.

Comment 16 Aleksandr Sharov 2020-09-16 09:52:54 UTC
Hi Florian!

Thank you for your explanation, but is there a way to make uge and krb5_libs coexist and don't utilise uge's libcrypto.so.1.1 ?

There's no sign of uge in ls.so.conf and none in LD_LIBRARY_PATH, DT_RPATH or DT_RUNPATH specified in the system, just general PATH and MANPATH and it's own variable:

[root@gotcentos8uge1t ~]# grep -i uge /etc/ld.so.conf* -r
[root@gotcentos8uge1t ~]# printenv | grep uge
SGE_ROOT=/opt/uge/default
MANPATH=/opt/uge/default/man:/usr/share/man:/usr/local/share/man
PATH=/opt/uge/default/bin/lx-amd64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

Thank you!

Comment 17 Florian Weimer 2020-09-16 10:22:56 UTC
I don't know what “uge” is and how it works.

You could run the failing process with LD_DEBUG=all, to see if there are any dynamic linker diagnostics that show why it augments the search path in this way.

Comment 22 Florian Weimer 2020-09-24 09:10:18 UTC
It turns out a non-system OpenSSL version was loaded, as a result of an RPATH setting in the main executable.


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