[392] in Kerberos
Re: ksu (really ticket lifetimes)
daemon@TELECOM.MIT.EDU (Jon Rochlis)
Mon Jun 13 14:10:14 1988
From: Jon Rochlis <jon@BITSY.MIT.EDU>
To: <qjb@ATHENA.MIT.EDU>
Cc: steiner@ATHENA.MIT.EDU, watchmakers@ATHENA.MIT.EDU,
In-Reply-To: Emanuel 'Jay' Berkenbilt's message of Mon, 13 Jun 88 11:20:50 EDT,
From: <qjb@ATHENA.MIT.EDU>
Date: Mon, 13 Jun 88 11:20:50 EDT
Why do kerberos tickets obtained "automatically" while ksu'ed only last for
ten minutes? This is rather inconvenient... Is there some deep security
reason? Is there any way to vary this?
This really belongs on "kerberos", not "watchmakers". The ten minute
lifetime is a feature. You can get longer-lasting tickets by using
"kinit -i" (or with the new kerberos stuff "kinit qjb.root") or by
making your own version of ksu (which you should only be using on a
workstation BTW, not on a server unless you are on the console or
otherwise have a secure path over which to type your root instance
password).
ksu specifically asks for ten-minute tickets so if you spaz and forget
about those tickets no harm will probably be done since they expire so
quickly. If you forget to do a kdestroy (exiting the ksu shell won't
do that for you!) this is a big win. The same rational is employed in
using a separate root instance as well. Your null instance tickets
are less important than your root instance tickets (not because of the
name "root" but rather because your root instance appears in access
control lists that lets you unix login as root for a given server).
Perhaps a user should be able to vary the life of his tickets. It is not
uncommon for a user to say something like, "I have a program that writes to
my nfs locker, and it is going to run for ten hours. I want to put up
the screensaver and go away. Can I do that?"
Writing to the nfs locker is a different issue. At the current time
mappings from uid,client to uid,nfs-server don't go away until the
locker is detached (or the server crashes). It is only when
establishing the mapping (at attach/mount time) that you need
non-expired kerberos tickets.
However, you can easily imagine other services who require valid
tickets as you suggest. I guess the real issue is the user interface.
At the moment how long your tickets last if a function of what program
did the get_in_tkt call and what it filled in for a "lifetime".
Perhaps what you're looking for is a -lifetime argument for kinit (or
login!).
In anycase, kerberos ticket lifetimes range between 0 and 255 and are
in units of five minutes, so the longest a ticket can last is 255 * 5
= 21.25 hours ... There have been some bugs found recently in
lifetime processing so we want to look carefully at this whole area (the
so-called "supertickets" on big-endian machines) and reports that
request initial tickets with a lifetime if -1 (i.e. 255) works
[tickets have a max lifetime in the database of eight hours, and any
new ticket is supposed to have a lifetime of the min of database
lifetime and the TGT used].
Some thought should also be given to the user-interface side of
notifying a user that tickets have expired.
-- Jon
