From kenh@cmf.nrl.navy.mil Thu Nov 14 12:42:01 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id MAA10186 for <bugs@RT-11.MIT.EDU>; Thu, 14 Nov 1996 12:42:00 -0500
Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP
id AA01562; Thu, 14 Nov 96 12:41:59 EST
Received: from elvis.cmf.nrl.navy.mil (kenh@elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.7.5/8.7.3) with ESMTP id MAA00250 for <krb5-bugs@mit.edu>; Thu, 14 Nov 1996 12:42:00 -0500 (EST)
Received: (kenh@localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) id MAA10837; Thu, 14 Nov 1996 12:41:53 -0500
Message-Id: <199611141741.MAA10837@elvis.cmf.nrl.navy.mil>
Date: Thu, 14 Nov 1996 12:41:53 -0500
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Reply-To: kenh@cmf.nrl.navy.mil
To: krb5-bugs@MIT.EDU
Subject: AFS token destroying code in login.c doesn't work
X-Send-Pr-Version: 3.2
System: SunOS elvis 4.1.3_U1 13 sun4m
Architecture: sun4
The code that destroys AFS tokens upon logout doesn't work. I'm not sure
how it was ever supposed to work, since it never actually calls
ktc_ForgetAllTokens().
(sleep 30; tokens) > /tmp/tokentest &
Logout, and observe that tokens still exist for that pag.
might be easier to comment out the code so people wouldn't think that it
actually works.
State-Changed-From-To: open-feedback
State-Changed-By: tytso
State-Changed-When: Fri Nov 15 17:49:33 1996
State-Changed-Why:
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: kenh@cmf.nrl.navy.mil
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Fri, 15 Nov 1996 17:51:04 -0500
From kenh@cmf.nrl.navy.mil Thu Nov 14 12:42:01 1996
Date: Thu, 14 Nov 1996 12:41:53 -0500
The code that destroys AFS tokens upon logout doesn't work. I'm not sure
how it was ever supposed to work, since it never actually calls
ktc_ForgetAllTokens().
Did you actually #define SETPAG when you compiled login.c? The code to
call ktc_ForgetAllTokens() is there, in afs_cleanup(), but you have to
define SETPAG before it will work. (try_unlog is #defined to be
try_afscall(ktc_ForgetAllTokens)).
- Ted
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Fri, 15 Nov 1996 17:56:52 -0500
SETPAG is defined if you use --with-afs, which I did.
Please look at try_afscall more closely ... you'll see that it doesn't
take an argument. So even if you do try_afscall(ktc_ForgetAllTokens),
ktc_ForgetAllTokens never actually gets called. It always calls setpag().
This code could have never worked, ever.
(I did triple-check this, honest :-) ).
--Ken
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, krb5-bugs@MIT.EDU
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Fri, 15 Nov 1996 18:43:57 -0500
So it does... yes, that's quite bad, isn't it? Thanks for pointing this
out!!
- Ted
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Fri, 15 Nov 1996 18:53:29 -0500
It all of a sudden occurs to me that if this code _does_ get fixed, please
make it possible to turn this behavior off, because there are some cases
where you don't want it to do that. For example, on machines that use
the AFS-NFS translator, there are no PAGs, and as a result if you clear
one login session's tokens, you clear them all.
(In one sense, I'm glad this is broken right now :-) ).
--Ken
Responsible-Changed-From-To: krb5-unassigned->epeisach
Responsible-Changed-By: tlyu
Responsible-Changed-When: Wed Nov 20 13:41:26 1996
Responsible-Changed-Why:
Ezra said he would deal.
State-Changed-From-To: feedback-analyzed
State-Changed-By: tlyu
State-Changed-When: Sat Jan 25 22:04:44 1997
State-Changed-Why:
I haven't seen any actual indications that a fix is happening yet.
Ezra?
From: Ezra Peisach <epeisach@MIT.EDU>
To: Tom Yu <tlyu@MIT.EDU>
Cc: kenh@cmf.nrl.navy.mil
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Sun, 26 Jan 1997 12:35:46 EST
The problem as indicated in the more recent bug report is that the parent
process does not know that the child process actually created a new PAG.
I had an obvious fix by moving the dofork later in the code - but then there is
the question about tty handling and Sam was not 100% sure at that late
date before release if it would all work... So we fixed the cosmetic bug,
knowing that it was not right yet - amnd I never got back to it...
(Outside proposition suddenly killed December for me).
Ezra
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Ezra Peisach <epeisach@MIT.EDU>
Cc: Tom Yu <tlyu@MIT.EDU>
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Sun, 26 Jan 1997 14:06:52 -0500
Okay, no problem ... didn't know that had happened.
IMHO, I think allocating the PAG before you fork, then running aklog after
you fork, would be the right thing to do.
--Ken
that it will work as intended. Note however that this does not fix the
problem yet of destroying tokens. Why? Because login.krb5 will fork if
it needs to destroy tickets/tokens (after the child returns from the
login shell) - a variable is set in the child process indicating that a
setpag is done (and works) but the parent process never finds this
out. Therefore the parent process will never do the unlog call.
A potential fix which works for OSF/1 is to move the dofork call way
down to before the exec of the child process shell, but I have some
serious questions regarding the while process group setup. For this
reason, this change was not made to source tree until it could be
examined and tested in more detail.
Ezra
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id MAA10186 for <bugs@RT-11.MIT.EDU>; Thu, 14 Nov 1996 12:42:00 -0500
Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP
id AA01562; Thu, 14 Nov 96 12:41:59 EST
Received: from elvis.cmf.nrl.navy.mil (kenh@elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.7.5/8.7.3) with ESMTP id MAA00250 for <krb5-bugs@mit.edu>; Thu, 14 Nov 1996 12:42:00 -0500 (EST)
Received: (kenh@localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) id MAA10837; Thu, 14 Nov 1996 12:41:53 -0500
Message-Id: <199611141741.MAA10837@elvis.cmf.nrl.navy.mil>
Date: Thu, 14 Nov 1996 12:41:53 -0500
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Reply-To: kenh@cmf.nrl.navy.mil
To: krb5-bugs@MIT.EDU
Subject: AFS token destroying code in login.c doesn't work
X-Send-Pr-Version: 3.2
Show quoted text
>Number: 190
>Category: krb5-appl
>Synopsis: AFS token destroying code in login.c doesn't work
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: epeisach
>State: analyzed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Nov 14 12:43:01 EST 1996
>Last-Modified: Sun Jan 26 22:28:00 EST 1997
>Originator: Ken Hornstein
>Organization:
Naval Research Lab>Category: krb5-appl
>Synopsis: AFS token destroying code in login.c doesn't work
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: epeisach
>State: analyzed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Nov 14 12:43:01 EST 1996
>Last-Modified: Sun Jan 26 22:28:00 EST 1997
>Originator: Ken Hornstein
>Organization:
Show quoted text
>Release: beta-7
>Environment:
>Environment:
System: SunOS elvis 4.1.3_U1 13 sun4m
Architecture: sun4
Show quoted text
>Description:
The code that destroys AFS tokens upon logout doesn't work. I'm not sure
how it was ever supposed to work, since it never actually calls
ktc_ForgetAllTokens().
Show quoted text
>How-To-Repeat:
Login using login.krb5, do(sleep 30; tokens) > /tmp/tokentest &
Logout, and observe that tokens still exist for that pag.
Show quoted text
>Fix:
I don't have fix right now, but I wanted people to be aware of this. Itmight be easier to comment out the code so people wouldn't think that it
actually works.
Show quoted text
>Audit-Trail:
State-Changed-From-To: open-feedback
State-Changed-By: tytso
State-Changed-When: Fri Nov 15 17:49:33 1996
State-Changed-Why:
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: kenh@cmf.nrl.navy.mil
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Fri, 15 Nov 1996 17:51:04 -0500
From kenh@cmf.nrl.navy.mil Thu Nov 14 12:42:01 1996
Date: Thu, 14 Nov 1996 12:41:53 -0500
The code that destroys AFS tokens upon logout doesn't work. I'm not sure
how it was ever supposed to work, since it never actually calls
ktc_ForgetAllTokens().
Did you actually #define SETPAG when you compiled login.c? The code to
call ktc_ForgetAllTokens() is there, in afs_cleanup(), but you have to
define SETPAG before it will work. (try_unlog is #defined to be
try_afscall(ktc_ForgetAllTokens)).
- Ted
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Fri, 15 Nov 1996 17:56:52 -0500
Show quoted text
>Did you actually #define SETPAG when you compiled login.c? The code to
>call ktc_ForgetAllTokens() is there, in afs_cleanup(), but you have to
>define SETPAG before it will work. (try_unlog is #defined to be
>try_afscall(ktc_ForgetAllTokens)).
>call ktc_ForgetAllTokens() is there, in afs_cleanup(), but you have to
>define SETPAG before it will work. (try_unlog is #defined to be
>try_afscall(ktc_ForgetAllTokens)).
SETPAG is defined if you use --with-afs, which I did.
Please look at try_afscall more closely ... you'll see that it doesn't
take an argument. So even if you do try_afscall(ktc_ForgetAllTokens),
ktc_ForgetAllTokens never actually gets called. It always calls setpag().
This code could have never worked, ever.
(I did triple-check this, honest :-) ).
--Ken
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, krb5-bugs@MIT.EDU
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Fri, 15 Nov 1996 18:43:57 -0500
So it does... yes, that's quite bad, isn't it? Thanks for pointing this
out!!
- Ted
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Fri, 15 Nov 1996 18:53:29 -0500
Show quoted text
>So it does... yes, that's quite bad, isn't it? Thanks for pointing this
>out!!
>out!!
It all of a sudden occurs to me that if this code _does_ get fixed, please
make it possible to turn this behavior off, because there are some cases
where you don't want it to do that. For example, on machines that use
the AFS-NFS translator, there are no PAGs, and as a result if you clear
one login session's tokens, you clear them all.
(In one sense, I'm glad this is broken right now :-) ).
--Ken
Responsible-Changed-From-To: krb5-unassigned->epeisach
Responsible-Changed-By: tlyu
Responsible-Changed-When: Wed Nov 20 13:41:26 1996
Responsible-Changed-Why:
Ezra said he would deal.
State-Changed-From-To: feedback-analyzed
State-Changed-By: tlyu
State-Changed-When: Sat Jan 25 22:04:44 1997
State-Changed-Why:
I haven't seen any actual indications that a fix is happening yet.
Ezra?
From: Ezra Peisach <epeisach@MIT.EDU>
To: Tom Yu <tlyu@MIT.EDU>
Cc: kenh@cmf.nrl.navy.mil
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Sun, 26 Jan 1997 12:35:46 EST
The problem as indicated in the more recent bug report is that the parent
process does not know that the child process actually created a new PAG.
I had an obvious fix by moving the dofork later in the code - but then there is
the question about tty handling and Sam was not 100% sure at that late
date before release if it would all work... So we fixed the cosmetic bug,
knowing that it was not right yet - amnd I never got back to it...
(Outside proposition suddenly killed December for me).
Ezra
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Ezra Peisach <epeisach@MIT.EDU>
Cc: Tom Yu <tlyu@MIT.EDU>
Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work
Date: Sun, 26 Jan 1997 14:06:52 -0500
Show quoted text
>The problem as indicated in the more recent bug report is that the parent
>process does not know that the child process actually created a new PAG.
>I had an obvious fix by moving the dofork later in the code - but then there
>is the question about tty handling and Sam was not 100% sure at that late
>date before release if it would all work... So we fixed the cosmetic bug,
>knowing that it was not right yet - amnd I never got back to it...
>process does not know that the child process actually created a new PAG.
>I had an obvious fix by moving the dofork later in the code - but then there
>is the question about tty handling and Sam was not 100% sure at that late
>date before release if it would all work... So we fixed the cosmetic bug,
>knowing that it was not right yet - amnd I never got back to it...
Okay, no problem ... didn't know that had happened.
IMHO, I think allocating the PAG before you fork, then running aklog after
you fork, would be the right thing to do.
--Ken
Show quoted text
>Unformatted:
Well, there are two problems in the code. I have fixed try_afscall() sothat it will work as intended. Note however that this does not fix the
problem yet of destroying tokens. Why? Because login.krb5 will fork if
it needs to destroy tickets/tokens (after the child returns from the
login shell) - a variable is set in the child process indicating that a
setpag is done (and works) but the parent process never finds this
out. Therefore the parent process will never do the unlog call.
A potential fix which works for OSF/1 is to move the dofork call way
down to before the exec of the child process shell, but I have some
serious questions regarding the while process group setup. For this
reason, this change was not made to source tree until it could be
examined and tested in more detail.
Ezra