Subject: Re: krb5 integration proposal
To: None <current-users@netbsd.org, tech-userlevel@netbsd.org>
From: Aidan Cully <aidan@kublai.com>
List: tech-userlevel
Date: 07/20/1999 13:01:41
After a fair bit of thought, and recognizing a major brain-o, I've
modified this proposal.. With no objections, I'll start importing this
stuff on Friday.
On Tue, Jun 08, 1999 at 09:43:09PM -0400, Aidan Cully wrote:
> 2) Merge in my kerb5 changes to login and rlogin. These build outside of
> domestic (for the most part), but still can require libcom_err.
login has already been changed.
> 3) Import domestic/krb5.
> Perhaps this directory should be domestic/dist/krb5?
I will be going with crypto-us/dist/krb5
> 4) Reorganize libtelnet, according to my local model.
> This means the following hierarchy:
> src/lib/libtelnet -- almost all libtelnet sources.
> src/lib/libtelnet/Nocrypt -- libtelnet source that might be overridden
> by crypto-enabled files.
> src/domestic/lib/libtelnet -- basically contains a reachover Makefile
> src/domestic/krb5/appl/telnet/libtelnet -- contains MIT's libtelnet
> source
>
> The src/lib/libtelnet Makefile will look something like
> .PATH: {$.CURDIR}/Nocrypt
> .include "${.CURDIR}/Makefile.inc"
> .include <bsd.lib.mk>
>
> where Makefile.inc contains almost everything in the current libtelnet
> Makefile.
>
> The src/domestic/lib/libtelnet Makefile will look something like
> .PATH: {$.CURDIR}/../../../lib/libtelnet
> .PATH: {$.CURDIR}/../../krb5/appl/telnet/libtelnet
> .include "${.CURDIR}/../../../lib/libtelnet/Makefile.inc"
>
> SRCS += kerberos5.c kerberos.c &c.
> .include <bsd.lib.mk>
The following to steps
> 5) Merge in the rest of the "reachover" parts of domestic/
> This will finally and forever break krb4, except for krb5's
> compatibility code.
> 6) Make krb4 a package (to help with people upgrading from k4, at least..)
will be changed to
5) import kerberos5 programs that share names with krb4 programs (e.g.,
kinit, kdestroy, &c.) as kinit5, kdestroy5, &c. Modify the
Makefile.frag in crypto-us/lib, crypto-us/usr.bin &c. like
.if (KERBEROS5 = "true")
# kerberos5 versions of utilities
SUBDIR+=${CRYPTOPATH}/kinit5 \
${CRYPTOPATH}/kdestroy5
&c.
.else
# kerberos4 versions of utilities
SUBDIR+=${CRYPTOPATH}/kinit \
${CRYPTOPATH}/kdestroy
&c.
.endif
so that we don't break k4 for people that want it.
> 7) Add krb5 support to other existing tools (ftpd, ftp, rsh..) following
> the libtelnet hierarchy.
> 8) Start work on other local changes, like libprotoauth which I proposed
> to kenh a long time ago.
>
>
> Stuff that looks troublesome:
> GSSRPC. On Ken Hornstein's advice, I've given up trying to merge libc's
> rpc implementation with krb5's gssrpc implementation.. There will be two
> RPC libraries installed on the system. (one of which is libc.)
> Where this breaks is in header files.. There should be only one set of
> header files for both the GSS and the _real_ RPC header files. I'm
> currently just using a bunch of #ifdef GSSAPI blocks in the RPC headers..
> I'm not sure how exportable this is, so the source RPC header files have
> been moved into domestic/, and we can use unifdef to generate exportable
> versions for src/include. There's probably a better method..
I've made a /usr/include/gssapi/rpc directory housing the GSSRPC headers.
This seems to work relatively well..
Any objections?
--aidan