Adding upstream version 2:4.20.0+dfsg.upstream/2%4.20.0+dfsg

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 335 insertions, 0 deletions

diff --git a/third_party/heimdal/appl/dceutils/README.original b/third_party/heimdal/appl/dceutils/README.original
new file mode 100644
index 0000000..0887023
--- /dev/null
+++ b/third_party/heimdal/appl/dceutils/README.original
@@ -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 than 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. 
+
+HOW TO INSTALL
+
+Examine the k5dfspag.c file to make sure the DFS syscalls are correct
+for your platform. See the /opt/dcelocal/share/include/dcedfs/syscall.h
+on Solaris for example. 
+
+You should build the testpag routine and make sure it works before 
+adding all the other mods. If it fails you can still use the klogind
+and telnetd with the k5prelogin and k5dcelogin code. 
+
+If you intend to install with a prefix other than /krb5, change:
+DPAGAIX and K5DCECON in k5dfspag.c; the three references in
+k5prelogin.c; and the DESTDIR in the Makefile.
+
+Get k5101.cdiff.xxxxxx.tar file and install the mods for ANL_DFS_PAG
+and ANL_DCE to the MIT Kerberos 5 source. These mods turn on some DCE
+related changes and the calls to krb5_dfs_pag. 
+
+Symlink or copy the k5dfspag.c to the src/lib/krb5/os directory. 
+
+Add the -DANL_DFS_PAG and -DANL_DCE flags to the configuration. 
+
+Configure and Build the Kerberos v5. 
+
+Modify the k5dce Makefile for your system. 
+
+Build the k5dcecon and related programs. 
+
+Install both the MIT Kerberos v5 and the k5dcecon and dpagaix if AIX.    
+
+The makefile can also build k5dcelogin and k5prelogin.  The install
+can install k5dcelogin, k5prelogin and update the links for login.krb5
+-> k5prelogin and moving login.krb5 to login.k5. If you will be using
+the k5dcecon/k5dfspag with the Kerberos mods, you don't need
+k5prelogin, or the links changed, and may not need k5dcelogin.
+
+Note that Transarc has obfuscated the entries to the lib, and 
+the 1.0.3a is different from the 1.1. You may need to build two
+versions of the k5dcelogin and/or k5dcecon one for each. 
+
+AIX ONLY
+
+The dpagaix routine is needed for AIX because of the way they do the 
+syscalls. 
+
+The following fix.aix.libdce.mk is not needed if dce 2.1.0.21
+has been installed. This PTF exposed the needed entrypoints. 
+
+The fix.aix.libdce.mk is a Makefile for AIX 4.x to add the required
+external entry points to the libdce.a.  These are needed by k5dcecon
+and k5dcelogin.  A bug report was submitted to IBM on this, and it was
+rejected. But since DCE 1.2.2 will have a k5dcelogin, this should not
+be needed with 1.2.2
+
+Copy /usr/lib/libdce.a to /usr/libdce.a.orig before starting. Copy the
+makefile to its own directory. It will create a new libdce.a which you
+need to copy back to /usr/lib/libdce.a You will need to reboot the
+machine.  See the /usr/lpp/dce/examples/inst/README.AIX for a similar
+procedure.  IBM was not responsive in a request to have these added.
+
+UNTESTED KERNEL EXTENSION FOR SETPAG
+
+*** src/file/osi/,osi_pag.c  Wed Oct  2 13:03:05 1996
+--- src/file/osi/osi_pag.c   Mon Jul 28 13:53:13 1997
+***************
+*** 293,298 ****
+--- 293,302 ----
+      int code;
+  
+      osi_MakePreemptionRight();
++    /* allow sharing of a PAG by non child processes DEE- 6/6/97 */
++    if (unused && osi_GetUID(osi_getucred()) == 0) {
++     newpag = unused;
++    } else {
+      osi_mutex_enter(&osi_pagLock);
+      now = osi_Time();
+      soonest = osi_firstPagTime +
+***************
+*** 309,314 ****
+--- 313,319 ----
+      }
+      osi_mutex_exit(&osi_pagLock);
+      newpag = osi_genpag();
++    }
+      osi_pcred_lock(p);
+      credp = crcopy(osi_getucred());
+      code = osi_SetPagInCred(credp, newpag);
+
+Created     07/08/96
+Modified    09/30/96
+Modified    11/19/96
+Modified    12/19/96
+Modified    06/20/97
+Modified    07/28/97
+Modified    02/18/98
+
+ Douglas E. Engert  <DEEngert@anl.gov>
+ Argonne National Laboratory
+ 9700 South Cass Avenue
+ Argonne, Illinois  60439 
+ (630) 252-5444