From daniel@unity.ncsu.edu Tue Feb 19 16:45:37 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id QAA11582 for ; Tue, 19 Feb 2002 16:45:36 -0500 (EST) Received: from stonecold.unity.ncsu.edu (stonecold.unity.ncsu.edu [152.1.4.139]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA28583 for ; Tue, 19 Feb 2002 16:45:36 -0500 (EST) Received: (from daniel@localhost) by stonecold.unity.ncsu.edu (8.8.4/EC02Jan97) id QAA01056; Tue, 19 Feb 2002 16:45:35 -0500 (EST) Message-Id: Date: Tue, 19 Feb 2002 16:45:35 -0500 (EST) From: Daniel Henninger Reply-To: daniel@ncsu.edu To: krb5-bugs@mit.edu Subject: Kerberos V 1.2.*: Bug(maybe?) with Kerberos IV support >Number: 1056 >Category: pending >Synopsis: Kerberos V 1.2.*: Bug(maybe?) with Kerberos IV support >Confidential: yes >Severity: serious >Priority: medium >Responsible: gnats-admin >State: open >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Tue Feb 19 16:46:00 EST 2002 >Last-Modified: >Originator: >Organization: >Release: >Environment: >Description: >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: Hi, I'm not sure if this was a design decision or not, or if there is just something screwy with the way I am compiling Krb5 on Solaris, but we are having problems with the Krb4 support. Specifically, it seems to be in_tkt.c. The short version of what's happening is, root can not read other user's ticket files. Was this a decision made on purpose? We have a lot of apps, such as our login code and/or pam modules, that perform the following steps, all done by root: 1. retrieve krb5 creds, using password 2. perform a krb524 convert on the krb5 creds 3. initialize a krb5 credential cache 4. place krb5 creds in 5. chown krb5 creds file to user and chmod it to only them 6. initialize a krb4 ticket file 7. place krb4 creds in 8. chown krb4 creds file to user and chmod it to only them - and here's where we have problems - After this step, we get the user's afs tokens, or at least theoretically. Because the krb4 ticket file is now owned by the user, root isn't able to store the krb4 creds it gets for the various afs cells in the ticket file for the user. Now, obviously, our fix for this was to move the chowns to after the afs part, but doing it the way outlined above used to work in pre-1.2.* Krb5. We've run into a lot of apps that have problems with this because they need to be able to add something to the user's credential cache as root, but can not. Do I need to start contacting developers and tell them they'll need to chown the ticket file to root first, add the ticket, and then chown it back or something else, or is this actually a bug? I tried to perform some patching to the krb5 code and, quite frankly, wasn't able to get very far. Commenting out: /* if (statpre.st_uid != me || !(statpre.st_mode & S_IFREG) || statpre.st_nlink != 1 || statpre.st_mode & 077) { if (krb_debug) fprintf(stderr,"Error initializing %s",file); return(KFAILURE); } This breaks things... */ helped -some- problems, but not all. Thanks! If I'm just doing something wrong, please let me know! =) Daniel -- /\\\----------------------------------------------------------------------///\ \ \\\ Daniel Henninger http://www.vorpalcloud.org/ /// / \_\\\ North Carolina State University - Systems Programmer ///_/ \\\ Information Technology /// """--------------------------------------------------------------"""