RT RT/krbdev.mit.edu: Ticket #1671 no locking used when reading/writing replay cache? Signed in as guest.
[Logout]

[Home] [Search] [Configuration]

[Display] [History] [Basics] [Dates] [People] [Links] [Jumbo]

 
 

 The Basics  
Id
1671
Status
new
Worked
0 min
Priority
0/0
Queue
krb5
 

 Keyword Selections  
Component
  • krb5-libs
Tags
Version_reported
Version_Fixed
Target_Version
 

 Relationships  
Depends on:
Depended on by:
Parents:
Children:

Refers to:
Referred to by:
  • 6289: (ghudson) replay cache is insecurely handled [resolved]
 
 Dates  
Created: Wed Jul 16 14:33:52 2003
Starts: Not set
Started: Not set
Last Contact: Not set
Due: Not set
Updated: Tue Jan 6 14:05:55 2009 by tlyu
 

 People  
Owner
 ghudson
Requestors
 hartmans@mit.edu
Cc
 
AdminCc
 
 

 More about Sam Hartman  
Comments about this user:
No comment entered about this user
This user's 25 highest priority tickets:
 

History   Display mode: [Brief headers] [Full headers]
      Wed Jul 16 14:33:53 2003  hartmans - Ticket created    
     
To: krb5-bugs@mit.edu
Subject: no  locking used when reading/writing replay cache?
From: Sam Hartman <hartmans@MIT.EDU>
Date: Wed, 16 Jul 2003 14:33:42 -0400

Return-Path: <kerberos-bounces@MIT.EDU>
Received: from solipsist-nation ([unix socket])
	by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Sat, 12 Jul
 2003 18:16:04 -0400
X-Sieve: CMU Sieve 2.2
Return-Path: <kerberos-bounces@MIT.EDU>
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
 [18.7.21.83])
	by suchdamage.org (Postfix) with ESMTP id 0DA5413207
	for <hartmans@suchdamage.org>; Sat, 12 Jul 2003 18:16:04 -0400 (EDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
	by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id
 h6CMFC3u028469;
	Sat, 12 Jul 2003 18:15:12 -0400 (EDT)
Received: from pch.mit.edu (localhost [127.0.0.1])
	by pch.mit.edu (8.12.8p1/8.12.8) with ESMTP id h6CLutk3004694;
	Sat, 12 Jul 2003 17:56:57 -0400 (EDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.12.8p1/8.12.8) with ESMTP id h6CLurk0004690
	for <kerberos@PCH.mit.edu>; Sat, 12 Jul 2003 17:56:53 -0400 (EDT)
Received: from pivsbh2.ms.com (pivsbh2.ms.com [199.89.64.104])
	h6CLuq3u025883
	for <kerberos@mit.edu>; Sat, 12 Jul 2003 17:56:52 -0400 (EDT)
Received: from pivsbh2.ms.com (localhost [127.0.0.1])
	by localhost.ms.com (Postfix) with SMTP id F1B27272EE
	for <kerberos@mit.edu>; Sat, 12 Jul 2003 17:56:51 -0400 (EDT)
Received: from ny16im01.ms.com (unknown [144.14.206.242])
	by pivsbh2.ms.com (internal Postfix) with ESMTP id D7CED262E8
	for <kerberos@mit.edu>; Sat, 12 Jul 2003 17:56:51 -0400 (EDT)
Received: from limus.ms.com (limus [144.14.15.176])
	by ny16im01.ms.com (Sendmail MTA Hub) with ESMTP id h6CLupa20369
	for <kerberos@mit.edu>; Sat, 12 Jul 2003 17:56:51 -0400 (EDT)
Received: (cesarg@localhost) by limus.ms.com (8.11.6/sendmail.cf.client
 v1.05)
	id h6CLupc27200; Sat, 12 Jul 2003 17:56:51 -0400
X-Mailer: 21.4 (patch 12) "Portable Code" XEmacs Lucid (via feedmail 10 I);
	VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
Message-ID: <16144.33827.362156.337126@limus.ms.com>
Date: Sat, 12 Jul 2003 17:56:51 -0400
From: Cesar Garcia <Cesar.Garcia@morganstanley.com>
To: kerberos@mit.edu
Subject: no file locking used when reading/writing replay cache?
X-BeenThere: kerberos@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Help: <mailto:kerberos-request@mit.edu?subject=help>
List-Post: <mailto:kerberos@mit.edu>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
	<mailto:kerberos-request@mit.edu?subject=subscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
	<mailto:kerberos-request@mit.edu?subject=unsubscribe>
Sender: kerberos-bounces@MIT.EDU
Errors-To: kerberos-bounces@MIT.EDU
X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK
 version=2.20
X-Spam-Level:
MIME-Version: 1.0

short:

There does not appear to be use of file locks when reading/writing to
replay cache files.

long:

We are implementing gss authentication via client and server side
security exits invoked by a vendor application. The application is
both multi-processed and multi-threaded. We have applied various
patches in order to get this code to run cleanly under Purify and use
a mutex in both the client and server side to serialize the entire
sequence of gss calls (within a single process only, of course).

Under extremely high load (note this involves multiple app-server
processes), we are getting SEGVs in our security exit. Unfortunately
the vendor product catches SEGV, so getting a core, stack trace, etc,
will involve some work.

In the mean time, I noticed that there is no use of file locking when
reading/writing to the replay cache. Unfortunately, I also don't have
copy of the replay cache file for us to examine. I wish I had more to
work with - I'm working with the application team to get better data.
However, even if this is not the cause of the problem we saw, I
thought it might be worth raising this issue.

Any insight would be appreciated.

Thanks,
Cesar
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos



Download (untitled) 4.1k
      Fri Aug 29 18:43:51 2003  raeburn - Component krb5-libs added    
      Tue Jan  6 14:05:55 2009  tlyu - Given to ghudson