[1845] in Kerberos-V5-bugs
Re: ss-962301 - krlogind and other fixes
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sun Mar 24 22:38:26 1996
Date: Sun, 24 Mar 1996 22:38:20 -0500
From: Sam Hartman <hartmans@MIT.EDU>
To: Doug Engert <DEEngert@anl.gov>
Cc: krb5-bugs@MIT.EDU
In-Reply-To: "[1837] in Kerberos-V5-bugs"
>>>>> "Doug" == Doug Engert <DEEngert@anl.gov> writes:
Doug> I have gotten some of the Kerberos 5 snapshot ss-962301
Doug> running on AIX 4.1.4 HPUX 10.0 and Solaris 2.4. This
Doug> includes the basic clients, krlogin and krlogind, and have
Doug> just touched telnet.
Thanks very much for your help with this. Also, sorry about
the spelling of your name in the ChangeLogs from your last set of
fixes.
Doug> I would like to report the following bugs/fixes. A context
Doug> diff file is attached:
Doug> ./src/util/pty/init_slave.c - Change the ifdefs around the
Doug> tests for streams. AIX 4.1.4 has streams, but unlike many of
Doug> the other systems which also have streams, it automaticly
Doug> pushed the ldterm, ptem and tioc stream modules on to the
Doug> stream. Thus the pushs are not needed. The ifdef for the
Doug> sun was moved so only the sun systems would push the
I implemented a static array at the top of init_slave.c that
describes what modules should be pushed. For example, if autoconf
defines PUSH_LDTERM, ldterm is pushed, else it isn't. I was concerned
that by the time we ended up dealing with other systems, the ifdefs in
init_slave.c would be as bad as telnetd.
Also, as a side note I was not able to repeat your success
pushing streams modules on an SGI. (I'm dealing with the fairly old
IRIX 5.2). In order to get it working on Irix, I had to end up using
_getpty.
Doug> ./src/util/pty/open_ctty.c - The test to see if the
Doug> controlling terminal is working was moved from this module
Doug> to the open_slave.c module after the pty_initialize_slave
Doug> routine. For the open("/dev/tty") to work, the stream must
Doug> be functioning. The HP failed this test originally.
Done. I'm not particularly happy with this solution long
term, but the other options (intializing the slave in open_ctty, or
passing in an initialization function) are even less acceptable, and
the old method certainly did break.
Doug> ./src/util/pty/open_slave.c - The return value from
Doug> pty_open_ctty is returned, and the test to see that the
Doug> controlling terminal is working was added after the call to
Doug> pty_initialize_slave. The #ifdef HAVE_REVOKE was moved, so
Doug> that ptyint_void_association was not called twice in a
Doug> row. ptyint_void_association did a setsid(), and it should
Doug> only do this once.
Actually, calling ptyint_void_association is OK; I am aware
that setsid will only work once, but Posix requires that it be a no-op
if called multiple times.
Doug> ./src/util/pty/void_assoc.c - A test was added for
Doug> TIOCNOTTY. One of the systems does not have it, and would
Doug> not compile.
Oops; added.
Doug> ./src/appl/bsd/krlogind.c - The AIX 4.1.4 system would crash
Doug> somewhere in login.krb5. Rather then debuging login.krb5, I
Doug> would rather see the vendor's login used if possible.
I have not yet dealt with the login problem. I don't really
like your solution because whether or not to use -f or -F should be
independent of what login you are using. The eventual solution will
probably deal with defining or not defining USE_KRB_LOGIN.
I agree with you that login.krb5 is not particularly useful
and that using vendor logins is often preferable. However, I think
that we (the Kerberos team) need to put some thought into how we deal
with this issue, as well as to how to integrate this issue with some
other upcoming changes to login handling.
(I'm not saying your solution isn't a reasonable interum fix for you,
just that this problem may not be solved in the next snapshot.)
Doug> Since the init_slave.c issues many of the same termio
Doug> changes, it was not clear why they are needed in
Doug> krlogind. Looks like some additional cleanup is needed. Also
Doug> the ISIG is turned off. login.krb5 turns it back on, but the
Doug> vendor's logins did not. This area need to be looked at more
Doug> closely.
ISIG is turned off so that the initial rlogin protocol over
the connection (performed by krlogind) will not create a problem; it
should not be turned off when using a vendor login.
The boundary between what pty_initialize_slave does and the
application does is somewhat unclear to me. Until I dcide what this
is, I don't want to remove code from rlogind.
I'm leaving your bug marked as open until the remaining
issues, including vendor logins are dealt with.
Doug> Douglas E. Engert Systems Programming Argonne
Doug> National Laboratory 9700 South Cass Avenue Argonne, Illinois
Doug> 60439 (708) 252-5444
Doug> Internet: DEEngert@anl.gov
