Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) X-RT-Original-Encoding: iso-8859-1 Content-Length: 7568 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 ; 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 ; 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 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 >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 >Release: beta-7 >Environment: System: SunOS elvis 4.1.3_U1 13 sun4m Architecture: sun4 >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(). >How-To-Repeat: Login using login.krb5, do (sleep 30; tokens) > /tmp/tokentest & Logout, and observe that tokens still exist for that pag. >Fix: I don't have fix right now, but I wanted people to be aware of this. It might be easier to comment out the code so people wouldn't think that it actually works. >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" 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 To: "Theodore Y. Ts'o" 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 >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)). 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" To: Ken Hornstein Cc: "Theodore Y. Ts'o" , 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 To: "Theodore Y. Ts'o" 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 >So it does... yes, that's quite bad, isn't it? Thanks for pointing this >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 To: Tom Yu 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 To: Ezra Peisach Cc: Tom Yu Subject: Re: krb5-appl/190: AFS token destroying code in login.c doesn't work Date: Sun, 26 Jan 1997 14:06:52 -0500 >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... 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 >Unformatted: Well, there are two problems in the code. I have fixed try_afscall() so 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