RT RT/krbdev.mit.edu: Ticket #3498 race opening/creating replay cache. Signed in as guest.
[Logout]

[Home] [Search] [Configuration]

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

 
 

 The Basics  
Id
3498
Status
resolved
Worked
0 min
Priority
0/0
Queue
krb5
 

 Keyword Selections  
Component
Tags
Version_reported
Version_Fixed
  • 1.13
Target_Version
  • 1.13
 

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

Refers to:
Referred to by:
  • 6289: (ghudson) replay cache is insecurely handled [resolved]
 
 Dates  
Created: Tue Mar 7 15:38:24 2006
Starts: Not set
Started: Fri Jun 9 19:45:14 2006
Last Contact: Thu Sep 18 16:46:10 2014
Due: Not set
Updated: Wed Dec 16 18:02:46 2015 by tlyu
 

 People  
Owner
 ghudson
Requestors
 elric@imrryr.org
Cc
 
AdminCc
 
 

 More about Roland C. Dowdeswell  
Comments about this user:
No comment entered about this user
This user's 25 highest priority tickets:
 

History   Display mode: [Brief headers] [Full headers]
      Tue Mar  7 15:38:26 2006  elric@imrryr.org - Ticket created    
     
To: krb5-bugs@mit.edu
Subject: race opening/creating replay cache.
Date: Mon, 06 Mar 2006 21:44:01 -0500
From: Roland Dowdeswell <elric@imrryr.org>

There is a race condition in the creation of the a replay cache,
or the replacement of a corrupt cache.  Basically, libraries when
opening a rcache do the following logic:

	1.  They try to open the file.

		a.  if the open succeeds

			i.   if the magic number matches, return success

			ii.  if not, unlink(2) the file.

	2.  They try to create the file with O_CREAT|O_EXCL.

	3.  They write the magic number in it.

Of course, if you have 2 processes doing this there is room for:

	There exists a time t s.t. both processes complete (1) before t
	and start (2) after t.

In this case, one of them will fail if either the file did not exist or
was malformed---i.e. had the wrong magic number in it.

This can be reproduced by running the following program:

/* $Id$ */

#include <stdio.h>
#include <string.h>

#include <krb5.h>

#define PRINC_NAME	"race"

#define K5BAIL(x)	do {					\
		code = (x);					\
		if (code) {					\
			fprintf(stderr, "%s: %s\n", #x,		\
			    error_message(code));		\
			exit(EXIT_FAILURE);			\
		}						\
	} while(0)

/*ARGSUSED*/
int
main(int argc, char **argv)
{
	krb5_context	ctx;
	krb5_error_code	code;
	krb5_rcache	rcache;
	krb5_data	piece;

	piece.data = strdup(PRINC_NAME);
	piece.length = strlen(piece.data);

	K5BAIL(krb5_init_context(&ctx));
	K5BAIL(krb5_get_server_rcache(ctx, &piece, &rcache));

	return 0;
}

To reproduce:

	1.  Run it under gdb(1), set a break point in krb5_rc_io_open(),

	2.  Step until you unlink the file,

	3.  Run another copy of the program,

	4.  continue the first one, and

	5.  Note that it fails.  With the rather unhelpful error
	    ``permission denied''.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/


Download (untitled) 1.6k
      Fri Jun  9 19:45:14 2006  raeburn - Status changed from new to open    
      Fri Jun  9 19:45:15 2006  raeburn - Comments added    
     
To reproduce the problem, I had to add:

  0) Create an invalid replay cache, e.g., "echo hello >
/var/tmp/race_7882".

This is what causes the first invocation of the program to unlink the
file rather than recover data from it.

With some patches I just checked in (rev 18102), the error message
should be a little less useless, if you call krb5_get_error_message:

krb5_get_server_rcache(ctx, &piece, &rcache): Cannot create replay
cache: File exists

This does nothing about the actual race condition itself, of course.


Download (untitled) 522b
      Tue Jan  6 14:07:23 2009  tlyu - Given to ghudson    
      Thu Sep 18 16:08:21 2014  ghudson - Target_Version 1.13 added    
      Thu Sep 18 16:08:21 2014  ghudson - Status changed from open to review    
      Thu Sep 18 16:08:21 2014  ghudson - Tags pullup added    
      Thu Sep 18 16:08:21 2014  ghudson - Correspondence added    
     
From: ghudson@mit.edu
Subject: git commit


Work around replay cache creation race

If two processes try to initialize the same replay cache at the same
time, krb5_rc_io_creat can race between unlink and open, leading to a
KRB5_RC_IO_PERM error.  When this happens, make the losing process
retry so that it can continue.

This does not solve the replay cache creation race, nor is that the
only replay cache race issue.  It simply prevents the race from
causing a spurious failure.

https://github.com/krb5/krb5/commit/c61e8c0c6ad5fda8d23dd896c4aed0ac5b470020
Author: Greg Hudson <ghudson@mit.edu>
Commit: c61e8c0c6ad5fda8d23dd896c4aed0ac5b470020
Branch: master
 src/lib/krb5/rcache/rc_io.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)


Download (untitled) 718b
      Thu Sep 18 16:46:10 2014  tlyu - Status changed from review to resolved    
      Thu Sep 18 16:46:10 2014  tlyu - Version_Fixed 1.13 added    
      Thu Sep 18 16:46:10 2014  tlyu - Correspondence added    
     
From: tlyu@mit.edu
Subject: git commit


Work around replay cache creation race

If two processes try to initialize the same replay cache at the same
time, krb5_rc_io_creat can race between unlink and open, leading to a
KRB5_RC_IO_PERM error.  When this happens, make the losing process
retry so that it can continue.

This does not solve the replay cache creation race, nor is that the
only replay cache race issue.  It simply prevents the race from
causing a spurious failure.

(cherry picked from commit c61e8c0c6ad5fda8d23dd896c4aed0ac5b470020)

https://github.com/krb5/krb5/commit/99e08376c14240e2141c6fa9289fafab8245c754
Author: Greg Hudson <ghudson@mit.edu>
Committer: Tom Yu <tlyu@mit.edu>
Commit: 99e08376c14240e2141c6fa9289fafab8245c754
Branch: krb5-1.13
 src/lib/krb5/rcache/rc_io.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)


Download (untitled) 824b
      Wed Dec 16 18:02:46 2015  tlyu - Keyword pullup deleted