Skip Menu |
 

Download (untitled) / with headers
text/plain 3.7KiB
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 <bugs@RT-11.mit.edu>; 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 <krb5-bugs@mit.edu>; 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: <Pine.GSO.4.44.0202191628560.977-100000@stonecold.unity.ncsu.edu>
Date: Tue, 19 Feb 2002 16:45:35 -0500 (EST)
From: Daniel Henninger <daniel@unity.ncsu.edu>
Reply-To: daniel@ncsu.edu
To: krb5-bugs@mit.edu
Subject: Kerberos V 1.2.*: Bug(maybe?) with Kerberos IV support

Show quoted text
>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 <IT> ///
"""--------------------------------------------------------------"""
To: rt@krbdev.mit.edu
Subject: [krbdev.mit.edu #1056]krb4 tickets cannot be read as root
Date: Mon, 11 Nov 2002 14:55:18 -0500 (EST)
From: hartmans@mit.edu (Sam Hartman)
RT-Send-Cc:


Hi. As you theorized in a ticket you opened this February, it is a
design decision that root cannot read other users' krb4 tickets.

I'm not sure why this design decision was made but we are not
interested in examining that decision at this point in the krb4 life
cycle.


Your PAM module and login programs should not be doing Kerberos
credentials cache operations as root. Instead, you should get tickets
as root into a memory cache, verify them against the host keytab, then
later in the setcred or open_session phase, seteuid to the user, write
out the credentials, and write out krb4 tickets. You can setpag and
get AFS tokens at this point or do it in a later PAM module, but you
should do so while setuid to the user.


Using seteuid instead of chown is very important because it will
continue to work even if we move towards Unix sockets or shared memory
for cache representations.
Date: Tue, 12 Nov 2002 09:34:17 -0500 (EST)
From: Daniel Henninger <daniel@unity.ncsu.edu>
To: Sam Hartman via RT <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #1056]krb4 tickets cannot be read as root
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.4KiB
Aha! Didn't think through it that way. Thanks much for the info!
I'll be glad when we can disable krb4 altogether anyway... =) Currently
AFS, Zephyrs, and Poppers are holding us back. Weee! (perhaps I had too
much caffeine this morning...)

Daniel

Show quoted text
> Your PAM module and login programs should not be doing Kerberos
> credentials cache operations as root. Instead, you should get tickets
> as root into a memory cache, verify them against the host keytab, then
> later in the setcred or open_session phase, seteuid to the user, write
> out the credentials, and write out krb4 tickets. You can setpag and
> get AFS tokens at this point or do it in a later PAM module, but you
> should do so while setuid to the user.
>
>
> Using seteuid instead of chown is very important because it will
> continue to work even if we move towards Unix sockets or shared memory
> for cache representations.
>
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> http://mailman.mit.edu/mailman/listinfo/krb5-bugs
>

--
/\\\----------------------------------------------------------------------///\
\ \\\ Daniel Henninger http://www.vorpalcloud.org/ /// /
\_\\\ North Carolina State University - Systems Programmer ///_/
\\\ Information Technology <IT> ///
"""--------------------------------------------------------------"""