Re: Debian /bin/login and heimdal kerberos

[Brian May <bam@snoopy.apana.org.au>]

On Mon, Jul 12, 1999 at 01:38:00PM +0200, Johan Danielsson wrote:
> Brian May <bam@snoopy.apana.org.au> writes:
> 
> > getopt is OK, it is the different standards for passing
> > parameters to login that is the problem.
> 
> Hmm, but `-f -- foo' is the same as `-f foo' with Single UNIX getopt

Ok - I will take you word for it.

However, it doesn't work with the login.c code. Maybe it is broken?
In case it is, here is the relevant part:

        while ((flag = getopt(argc, argv, "d:f:h:pr:")) != EOF) {
                switch (flag) {
[...]
                case 'f':
                        /*
                         * username must be a separate token
                         * (-f root, *not* -froot).  --marekm
                         */
                        if (optarg != argv[optind - 1])
                                usage();
                        fflg++;
                        STRFCPY(name, optarg);
                        break;
[...]

> (if -f doesn't take an argument).

Hang on - yes '-f' is defined to take an argument. So I believe the
behaviour I have seen to be correct. My guess would be to change the
above so that -f doesn't take an argument, and change the
following code:

        if (optind < argc) {            /* get the user name */
                if (rflg || fflg)
                        usage();

#ifdef SVR4
                /*
                 * The "-h" option can't be used with a command-line username,
                 * because telnetd invokes us as: login -h host TERM=...
                 */

                if (! hflg)
#endif
                {
                        STRFCPY(name, argv[optind]);
                        ++optind;
                }
        }

so that it doesn't test specifically for the "fflg" before displaying
usage information. I have already done a similar thing, but
it is a bit messy right now. Comments? Would this break anything?

> > I don't understand. What reason is it that you don't do it? What
> > don't you do?
> 
> We don't unlink the ticket file on logout because login can't know
> that there isn't any processes left using it.

You mean background processes? 

> > My solution for deleting the ticket file after you log out works fine...
> 
> But requires you to use a per-tty (or per-process) ccache (which might
> be ok in most cases).
> 
> We could add this to our login, but I personally doesn't want this
> functionality. I feel this should be left to the individual user to
> decide.

Individual user or individual system administrator?

There are two issues that seem to be under debate here:
1. Should the ticket be named per-login?
2. Should the ticket be deleted automatically on logout?

(It should go without saying that 2 without 1 is a bad idea).

1. Could be solved by copying $KRB5CCNAME to a new name in user's
login script. However, this would mean overwriting the default ticket
file on each login. This is not good. Imagine two users with two
different principles logging into the same account at the same time with
forwarding turned on... (assume that both users trust each other - maybe
both principles are the same user in fact) - a race condition exists.

I would suggest a better method would be to have a per-login ticket, but
if you don't like it, you can always copy it to the default location in
your login files.

2. Could be solved by deleting $KRB5CCNAME in users logout script.

There are certain other issues involved here (like all my xterms start a
new login session). I haven't thought about these implications yet.

-- 
Brian May <bam@snoopy.apana.org.au>

PGP signature