Skip Menu |

Download (untitled) / with headers
text/plain 3.5KiB
From Thu Apr 20 19:46:27 2000
by (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 (980427.SGI.8.8.8/980728.SGI.AUTOCF) id TAA02795; Thu, 20 Apr 2000 19:46:26 -0400 (EDT)
Message-Id: <>
Date: Thu, 20 Apr 2000 19:46:26 -0400 (EDT)
From: (Youssef Marzouk)
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
>Originator: Youssef Marzouk
MIT, Dept of Mechanical Engineering
Show quoted text
>Release: krb5-1.1.1
>Environment:, IRIX64 6.5.7f, IP26
System: IRIX64 centaur 6.5 01200451 IP26

Show quoted text
When connected to the machine from a remote host via telnetd,
many applications are unable to link to their run-time shared objects
( 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 '' 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
Connect to the machine from any kind of remote host via the telnetd
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

Show quoted text
No fix... so any ideas or explanations you have would be quite
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!

Show quoted text
Subject: rld errors or environment/capability problems via telnetd
In general we don't consider variances between the Kerberos login process and
the login process provided by the initial system as a bug; as such I'm closing this.
It does not surprise me that you get different capabilities with Kerberos telnetd; emulating
all the different OS behaviors is out of scope for our distribution.