[src/netbsd-1-5]: src/crypto/dist/heimdal/appl/dceutils Pull up revision 1.1....

[he <he%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/a98adb817cc1
branches:  netbsd-1-5
changeset: 491141:a98adb817cc1
user:      he <he%NetBSD.org@localhost>
date:      Thu Apr 05 23:24:20 2001 +0000

description:
Pull up revision 1.1.1.1 (requested by assar):
  Upgrade Heimdal to version 0.3e.

diffstat:

 crypto/dist/heimdal/appl/dceutils/README.dcedfs   |   59 +
 crypto/dist/heimdal/appl/dceutils/README.original |  335 +++++++++
 crypto/dist/heimdal/appl/dceutils/compile         |   82 ++
 crypto/dist/heimdal/appl/dceutils/dfspag.exp      |    3 +
 crypto/dist/heimdal/appl/dceutils/dpagaix.c       |   23 +
 crypto/dist/heimdal/appl/dceutils/k5dce.h         |  165 ++++
 crypto/dist/heimdal/appl/dceutils/k5dcecon.c      |  791 ++++++++++++++++++++++
 7 files changed, 1458 insertions(+), 0 deletions(-)

diffs (truncated from 1486 to 300 lines):

diff -r 448cfc949703 -r a98adb817cc1 crypto/dist/heimdal/appl/dceutils/README.dcedfs
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/crypto/dist/heimdal/appl/dceutils/README.dcedfs   Thu Apr 05 23:24:20 2001 +0000
@@ -0,0 +1,59 @@
+This is a set of patches and files to get a DFS ticket from a k5 ticket.
+This code comes from Doug Engert, Argonne Nat. Lab (See dce/README.original
+for more info)
+
+The files in dce are;
+testpag: for testing if this is at all possible.
+k5dfspag: included in libkrb5
+k5dcecon: Creates (or searches for) the actual DFSPAG ticketfile.
+dpagaix: An AIX syscall stub.
+README.original: Original README file from Doug Engert
+
+
+Certain applications (rshd/telnetd) have been patched to call the
+functions in k5dfspag when the situation is right. They are ifdef
+with DCE. The patches are also originally from Doug but they
+where against MIT krb5 code and have been merged into heimdal by me.
+I will try to fix ftpd soon...
+
+There is also an ifdefs for DCE && AIX that can be used to make AIX
+use DCE for getting group/passwd entries. This is needed if one is running
+with a bare bones passwd/group file and AUTHSTATE set to DCE (This will be
+more or less clear to people doing this...) I have forced this on for now.
+
+k5dfspag.c is in lib/krb5
+k5dfspag.c is dependent on DCE only.
+It is also POSIX systems only. There are defines for the location of
+k5dcecon and dpagaix that needs a correct configure setting.
+
+k5dcecon needs no special things for the compile except whatever is needed
+on the target system to compile dce programs.
+(On aix the dce compile flags are: -D_THREAD_SAFE -D_AIX32_THREADS=1 -D_AIX41 -D_AES_SOURCE or one can use xlc_r4 if it is version 3.6.4 or later)
+
+k5dcecon wants the following libs (on aix 4.3):
+-ldce (and setenv from somewhere)
+
+dpagaix is only needed on AIX (see k5dfspag.c).
+dpagaix needs dfspag.exp and is linked with
+ld -edpagaix -o dpagaix dpagaix.o dfspag.exp
+
+
+Hope to get this into heimdal soon :-) although I know that you will have to
+change some things to get it cleanly into configure. Since I don't know the
+structure of the code (heimdal), nor enough of configure, good enough I
+just won't try it myself.
+
+One more thing, to get this to work one has to put fcache_version = x in
+krb5.conf where x = whatever the DCE implementation understands, (usually
+1 or 2).
+Thanks for adding that...
+
+
+Åke Sandgren (ake%hpc2n.umu.se@localhost)
+HPC2N
+Umeå University
+Sweden
+
+PS
+I have now added patches for configure.in and some Makefile.am's to get this
+all cleanly (I hope) into heimdal.
diff -r 448cfc949703 -r a98adb817cc1 crypto/dist/heimdal/appl/dceutils/README.original
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/crypto/dist/heimdal/appl/dceutils/README.original Thu Apr 05 23:24:20 2001 +0000
@@ -0,0 +1,335 @@
+KERBEROS and DCE INTEROPERABILITY ROUTINES
+
+WHAT'S NEW
+
+When k5dcecon was examining the ticket caches looking to 
+update one with a newer TGT, it might update the wrong
+one for the correct user.  This problem was reported by PNNL,
+and is now fixed.
+
+Any Kerberized application can now use a forwarded TGT to establish a
+DCE context, or can use a previously established DCE context. This is
+both a functional improvement and a performance improvement.
+
+BACKGROUND
+
+The MIT Kerberos 5 Release 1.x and DCE 1.1 can interoperate in a
+number of ways. This is possible because:
+
+ o DCE used Kerberos 5 internally. Based on the MIT code as of beta 4
+   or so, with additional changes. 
+
+ o The DCE security server can act as a K5 KDC, as defined in RFC 1510
+   and responds on port 88. 
+
+ o On the clients, DCE and Kerberos use the same format for the ticket
+   cache, and then can share it. The KRB5CCNAME environment variable points
+   at the cache.   
+ 
+ o On the clients, DCE and Kerberos use the same format for the srvtab
+   file. DCE refers to is a /krb5/v5srvtab and Kerberos as
+   /etc/krb5.keytab. They can be symlinked.  
+
+ o MIT has added many options to the krb5.conf configuration file
+   which allows newer features of Release 1.0 to be turned off to match
+   the earlier version of Kerberos upon which DCE is based. 
+
+ o DCE will accept a externally obtained Kerberos TGT in place of a
+   password when establishing a DCE context. 
+
+There are some areas where they differ, including the following:
+ 
+ o Administration of the database and the keytab files is done by the
+   DCE routines, rather the the Kerberos kadmin.
+
+ o User password changes must be done using the DCE commands. Kpasswd
+   does not work. (But there are mods to Kerberos to use the v5passwd 
+   with DCE.  
+
+ o DCE goes beyond authentication only, and provides authorization via
+   the PAC, and the dce-ptgt tickets stored in the cache. Thus a
+   Kerberos KDC can not act as a DCE security server. 
+
+ o A DCE cell and Kerberos realm can cross-realm authenticate, but 
+   there can be no intermediate realms. (There are other problems
+   in this area as well. But directly connected realms/cells do work.)
+
+ o You can't link a module with the DCE library and the Kerberos
+   library. They have conflicting routines, static data and structures.  
+ 
+One of the main features of DCE is the Distributed File System
+DFS. Access to DFS requires authentication and authorization, and when
+one uses a Kerberized network utility such as telnet, a forwarded
+Kerberos ticket can be used to establish the DCE context to allow
+access to DFS.  
+
+
+NEW TO THIS RELEASE
+
+This release introduces sharing of a DCE context, and PAG, and allows
+any Kerberized application to establish or share the context. This is
+made possible by using an undocumented feature of DCE which is on at
+least the Transarc and IBM releases of DCE 1.1.
+
+I am in the process of trying to get this contributed to the general
+DCE 1.2.2 release as a patch, so it could be included in other vendors
+products.  HP has expressed interest in doing this, as well as the
+OpenGroup if the modification is contributed. You can help by
+requesting Transarc and/or IBM to submit this modification to the
+OpenGroup and ask your vendor to adopt this modification.
+
+The feature is a modification to the setpag() system call which will
+allow an authorized process to set the PAG to a specific value, and
+thus allow unrelated processes to share the same PAG.
+
+This then allows the Kerberized daemons such as kshd, to exec a DCE
+module which established the DCE context. Kshd then sets the
+KRB5CCNAME environment variable and then issues the setpag() to use
+this context. This solves the linking problem. This is done via the
+k5dfspag.c routine.
+
+The k5dfspag.c code is compiled with the lib/krb5/os routines and
+included in the libkrb5. A daemon calls krb5_dfs_pag after the
+krb5_kuserok has determined that the Kerberos principal and local
+userid pair are acceptable. This should be done early so as to give
+the daemon access to the home directory which may be located on DFS.  
+If the .k5login file is used by krb5_kuserok it will need to be
+accessed by the daemon and will need special ACL handling.  
+
+The krb5_dfs_pag routine will exec the k5dcecon module to do all the
+real work. Upon return, if a PAG is obtained, krb5_dfs_pag with set
+the PAG for the current process to the returned PAG value. It will
+also set the KRB5CCNAME environment as well. Under DCE the PAG value
+is the nnnnnnn part of the name of the cache:
+FILE:/opt/dcelocal/var/security/creds/dcecred_nnnnnnnn. 
+
+The k5dcecon routine will attempt to use TGT which may have been
+forwarded, to convert it to a DCE context. If there is no TGT, an
+attempt will be made to join an existing PAG for the local userid, and
+Kerberos principal. If there are existing PAGs, and a forwarded TGT,
+k5dcecon will check the lifetime of the forwarded TGT, and if it is
+less then the lifetime of the PAG, it will just join the PAG. If it
+is greater, it will refresh the PAG using the forwarded TGT. 
+This approach has the advantage of not requiring many new tickets from
+having to be obtained, and allows one to refresh a DCE context, or use
+an already established context. 
+
+If the system also has AFS, the AFS krb5_afs_pag should be called
+after the krb5_dfs_pag, since cache pointed at via the KRB5CCNAME may
+have changed, such as if a DFS PAG has been joined. The AFS code does
+not have the capability to join an existing AFS PAG, but can use the
+same cache which might already had a
+afsx/<afs.cell.name>@<k5.realm.name> service ticket.
+
+
+WHAT'S IN THIS RELEASE
+
+The k5prelogin, k5dcelogin, k5afslogin (with ak5log) were designed to
+be slipped in between telnetd or klogind and login.krb5. They would
+use a forwarded Kerberos ticket to establish a DCE context.  They are
+the older programs which are included here. They work on all DCE
+platforms, and don't take advantage of the undocumented setpag
+feature. (A version of k5dcelogin is being included with DCE 1.2.2)
+ 
+K5dcecon is the new program which can be used to create, update or
+join a DCE context. k5dcecon returns KRB5CCNAME string which contains
+the PAG.
+
+k5dfspag.c is to be built in the MIT Kerberos 5 release 1.0 patchlevel
+1 and added to the libkrb5. It will exec k5dcecon and upon return set
+the KRB5CCNAME and PAG. Mods to Kerberized klogind, rshd, telnetd,
+ftpd are available to use the k5dfspag. 
+
+Testpag.c is a test programs to see if the PAG can be set.
+
+The cpwkey.c routine can be used to change a key in the DCE registry,
+by adding the key directly, or by setting the salt/pepper and password
+or by providing the key and the pepper. This could be useful when
+coping keys from a K4 or AFS database to DCE. It can also be used when
+setting a DCE to K5 cross-cell key.  This program is a test program
+For mass inserts, it should be rewritten to read from stdin.
+
+K5dcelogin can also be called directly, much like dce_login.
+I use the following commands in effect do the same thing as dce_login
+and get a forwardable ticket, DCE context and an AFS token:
+
+  #!/bin/csh
+  # simulate a dce_login using krb5 kinit and k5dcelogin
+  #
+  setenv KRB5CCNAME FILE:/tmp/krb5cc_p$$
+  /krb5/bin/kinit -f
+  exec /krb5/sbin/k5dcelogin /krb5/sbin/k5afslogin /bin/csh
+  #exec /krb5/sbin/k5dcelogin  /bin/csh
+
+This could be useful in a mixed cell where "AS_REQ" messages are
+handled by a K5 KDC, but DCE RPCs are handled by the DCE security
+server.
+
+TESTING THE SETPAG
+
+The krb5_dfs_pag routine relies on an undocumented feature which is
+in the AIX and Transarc Solaris ports of DCE and has been recently
+added to the SGI version.  To test if this feature is present 
+on some other DFS implementation use the testpag routine. 
+
+The testpag routine attempts to set a PAG value to one you supply. It
+uses the afs_syscall with the afs_setpag, and passes the supplied 
+PAG value as the next parameter. On an unmodifed system, this 
+will be ignored, and a new will be set. You should also check that
+if run as a user, you cannot join a PAG owned by another user. 
+When run as root, any PAG should be usable. 
+
+On a machine with DFS running, do a dce_login to get a DCE context and
+PAG. ECHO the KRB5CCNAME and look at the nnnnnnnn at the end. It
+should look like an 8 char hex value, which may be 41ffxxxx on some
+systems. 
+
+Su to root and unsetenv KRB5CCNAME. Do a testpag -n nnnnnnnn where
+nnnnnnnn is the PAG obtained for the above name. 
+
+It should look like this example on an AIX 4.1.4 system:
+
+   pembroke# ./testpag -n 63dc9997
+   calling k5dcepag newpag=63dc9997
+   PAG returned = 63dc9997
+
+You will be running under a new shell with the PAG and KRB5CCNAME set.
+If the PAG returned is the same as the newpag, then it worked. You can
+further verify this by doing a DCE klist, cd to DFS and a DCE klist
+again. The klist should show some tickets for DFS servers.
+
+If the PAG returned is not the same, and repeated attempts show a
+returned PAG decremented by 1 from the previous returned PAG, then
+this system does not have the modification For example: 
+ 
+   # ./testpag -n 41fffff9
+   calling k5dcepag newpag=41fffff9
+   PAG returned = 41fffff8
+   # ./testpag -n 41fffff9
+   calling k5dcepag newpag=41fffff9
+   PAG returned = 41fffff7
+
+In this case the syscall is ignoring the newpag parameter. 
+
+Running it with -n 0 should get the next PAG value with or without
+this modification. 
+
+If the DFS kernel extensions are not installed, you would get
+something like this:
+
+  caliban.ctd.anl.gov% ./testpag -n 012345678
+  calling k5dcepag newpag=012345678
+  Setpag failed with a system error
+  PAG returned = ffffffff
+  Not a good pag value
+
+If you DFS implementation does not have this modification, you could
+attempt to install it yourself. But this requires source and requires
+modifications to the kernel extensions. At the end of this note is an
+untested sample using the DCE 1.2.2 source code. You can also contact
+your system vendor and ask for this modification.
+
+UNICOS has a similar function setppag(newpag) which can be used to set
+the PAG of the parent. Contact me if you are interested.