From ymarz@centaur.mit.edu Thu Apr 20 19:46:27 2000
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
by rt-11.mit.edu (8.9.3/8.9.3) with SMTP id TAA22910
for <bugs@RT-11.MIT.EDU>; Thu, 20 Apr 2000 19:46:27 -0400 (EDT)
Received: from CENTAUR.MIT.EDU by MIT.EDU with SMTP
id AA28203; Thu, 20 Apr 00 19:48:23 EDT
Received: (from ymarz@localhost) by centaur.mit.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) id TAA02795; Thu, 20 Apr 2000 19:46:26 -0400 (EDT)
Message-Id: <200004202346.TAA02795@centaur.mit.edu>
Date: Thu, 20 Apr 2000 19:46:26 -0400 (EDT)
From: ymarz@centaur.mit.edu (Youssef Marzouk)
Reply-To: ymarz@centaur.mit.edu
To: krb5-bugs@MIT.EDU
Subject: rld errors or environment/capability problems via telnetd
X-Send-Pr-Version: 3.99
System: IRIX64 centaur 6.5 01200451 IP26
many applications are unable to link to their run-time shared objects
(libxxx.so) and thus unable to execute. For instance, invoking f90
returns the following sort of errors from rld:
2829:/usr/lib32/cmplrs/be: rld: Fatal Error: Cannot Successfully map
soname 'be.so' under any of the filenames ... (et cetera)
The same type of errors occur for numerous other applications, both
local and IRIX-included, such as acroread, matlab, and
tecplot. Modifying the LD_LIBRARY_PATH environment variable to include
the library paths for these applications doesn't work (and would be a
cumbersome workaround even if it did work, as you'd have to know the
path to each application's own directory of so's).
This error occurs regardless of whether authentication is actually
used or not. But it *does not* occur when I replace the telnetd that
came with kerberos with the original telnetd that came with IRIX
(/usr/etc/telnetd) (that is, I fix inetd.conf so the original telnetd
is enabled.) So something is apparently wrong with the login process
that is initiated by the telnetd in the kerberos distribution.
Doing printenv doesn't show any environment variables to be
amiss. Doing id -P shows a funny set of capabilities (like
CAP_DAC_WRITE+pi) that shouldn't belong to a standard user, so that's
at least a tipoff that something is amiss. I'm still not sure of the
direct mechanism that leads backwards from rld problems to some
problem in the login process, but by deduction it seems to be related
to the telnetd.
This may be useful, or it may not, but my shell is tcsh. The problem
occurs no matter what kind of remote host I'm using (it even occurs
when telnetting from centaur to itself).
provided with the Kerberos V5 1.1.1 binaries built for Irix 6.5 (on
the MIT distribution site). Try to run applications like acroread,
f90, matlab, and numerous others. Errors from rld will prevent their
execution.
useful. One work-around: After connecting to the machine via the
kerberos-distributed telnetd, type login go through the log-in process
again. Once I do this, everything works!
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
by rt-11.mit.edu (8.9.3/8.9.3) with SMTP id TAA22910
for <bugs@RT-11.MIT.EDU>; Thu, 20 Apr 2000 19:46:27 -0400 (EDT)
Received: from CENTAUR.MIT.EDU by MIT.EDU with SMTP
id AA28203; Thu, 20 Apr 00 19:48:23 EDT
Received: (from ymarz@localhost) by centaur.mit.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) id TAA02795; Thu, 20 Apr 2000 19:46:26 -0400 (EDT)
Message-Id: <200004202346.TAA02795@centaur.mit.edu>
Date: Thu, 20 Apr 2000 19:46:26 -0400 (EDT)
From: ymarz@centaur.mit.edu (Youssef Marzouk)
Reply-To: ymarz@centaur.mit.edu
To: krb5-bugs@MIT.EDU
Subject: rld errors or environment/capability problems via telnetd
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 848
>Category: telnet
>Synopsis: rld errors or environment/capability problems via telnetd
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: hartmans
>State: open
>Class: support
>Submitter-Id: unknown
>Arrival-Date: Thu Apr 20 19:47:00 EDT 2000
>Last-Modified:
>Originator: Youssef Marzouk
>Organization:
MIT, Dept of Mechanical Engineering>Category: telnet
>Synopsis: rld errors or environment/capability problems via telnetd
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: hartmans
>State: open
>Class: support
>Submitter-Id: unknown
>Arrival-Date: Thu Apr 20 19:47:00 EDT 2000
>Last-Modified:
>Originator: Youssef Marzouk
>Organization:
Show quoted text
>Release: krb5-1.1.1
>Environment:
centaur.mit.edu, IRIX64 6.5.7f, IP26>Environment:
System: IRIX64 centaur 6.5 01200451 IP26
Show quoted text
>Description:
When connected to the machine from a remote host via telnetd,many applications are unable to link to their run-time shared objects
(libxxx.so) and thus unable to execute. For instance, invoking f90
returns the following sort of errors from rld:
2829:/usr/lib32/cmplrs/be: rld: Fatal Error: Cannot Successfully map
soname 'be.so' under any of the filenames ... (et cetera)
The same type of errors occur for numerous other applications, both
local and IRIX-included, such as acroread, matlab, and
tecplot. Modifying the LD_LIBRARY_PATH environment variable to include
the library paths for these applications doesn't work (and would be a
cumbersome workaround even if it did work, as you'd have to know the
path to each application's own directory of so's).
This error occurs regardless of whether authentication is actually
used or not. But it *does not* occur when I replace the telnetd that
came with kerberos with the original telnetd that came with IRIX
(/usr/etc/telnetd) (that is, I fix inetd.conf so the original telnetd
is enabled.) So something is apparently wrong with the login process
that is initiated by the telnetd in the kerberos distribution.
Doing printenv doesn't show any environment variables to be
amiss. Doing id -P shows a funny set of capabilities (like
CAP_DAC_WRITE+pi) that shouldn't belong to a standard user, so that's
at least a tipoff that something is amiss. I'm still not sure of the
direct mechanism that leads backwards from rld problems to some
problem in the login process, but by deduction it seems to be related
to the telnetd.
This may be useful, or it may not, but my shell is tcsh. The problem
occurs no matter what kind of remote host I'm using (it even occurs
when telnetting from centaur to itself).
Show quoted text
>How-To-Repeat:
Connect to the machine from any kind of remote host via the telnetdprovided with the Kerberos V5 1.1.1 binaries built for Irix 6.5 (on
the MIT distribution site). Try to run applications like acroread,
f90, matlab, and numerous others. Errors from rld will prevent their
execution.
Show quoted text
>Fix:
No fix... so any ideas or explanations you have would be quiteuseful. One work-around: After connecting to the machine via the
kerberos-distributed telnetd, type login go through the log-in process
again. Once I do this, everything works!
Show quoted text
>Audit-Trail:
>Unformatted:
>Unformatted: