Bug 49437 - xauth file grows to system limit (from su)
Summary: xauth file grows to system limit (from su)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pam
Version: 7.1
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Aaron Brown
URL:
Whiteboard:
: 49386 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-19 15:41 UTC by Daniel Morris
Modified: 2007-04-18 16:34 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-11-01 13:42:01 UTC
Embargoed:


Attachments (Terms of Use)
This patch fixed the problem for me. I added it to the SPEC file with -p1. (587 bytes, patch)
2001-07-27 13:06 UTC, John Dalbec
no flags Details | Diff

Description Daniel Morris 2001-07-19 15:41:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.5-0.2.9 i686)

Description of problem:
On doing 'su -' it has hit a file system limit (after successful
password). This is from a terminal within an X session. The su
attempt then fails.

How reproducible:
Always

Steps to Reproduce:
1. su - (over a period of time)
2. manifests itself everytime thereafter
3.
	

Actual Results:  File size limit exceeded

Expected Results:  root prompt!

Additional info:

I've tracked this to the following file:

-rw-------    1 danielm  danielm  1048576000 Jul 18 22:32
+/home/danielm/.xauth/refcount/root/sloth.ammanford.redhat.com/unix:0


Which is a bit large! file reports "ASCII text, with no line terminators"
and it appears to contain the string:
1 257d881eb2c44c115e3ddb388d390d38
then followed by NULL's.

Why has su done this? This is on a clean 7.1 x86 install and has
taken about 3 weeks to get to this stage. Here is are the final actions
of su:

--- SIGCHLD (Child exited) ---
read(3, "0100 001a 736c6f74682e616d6d616e"..., 256) = 151
read(3, "", 105)                        = 0
wait4(1565, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 1565
close(3)                                = 0
close(4)                                = -1 EBADF (Bad file descriptor)
setfsuid32(0x1f4)                       = 0
mkdir("/home/danielm/.xauth", 0700)     = -1 EEXIST (File exists)
mkdir("/home/danielm/.xauth/refcount", 0700) = -1 EEXIST (File exists)
mkdir("/home/danielm/.xauth/refcount/root", 0700) = -1 EEXIST (File exists)
mkdir("/home/danielm/.xauth/refcount/root/sloth.ammanford.redhat.com",
0700) =
+-1 EEXIST (File exists)
stat64("/home/danielm/.xauth/refcount/root/sloth.ammanford.redhat.com/unix:0",
+{st_mode=S_IFREG|0600, st_size=1048576000, ...}) = 0
open("/home/danielm/.xauth/refcount/root/sloth.ammanford.redhat.com/unix:0",
+O_RDWR|O_CREAT, 0600) = 3
ftruncate(3, 1048576035)                = -1 EFBIG (File too large)
--- SIGXFSZ (File size limit exceeded) ---


I'm a bit surprised that ftruncate is trying to make the file bigger,
which is probably where the NULL's have come from. Is there some
bad cleanup logic?

 Daniel

Comment 1 John Dalbec 2001-07-20 20:56:41 UTC
*** Bug 49386 has been marked as a duplicate of this bug. ***

Comment 2 John Dalbec 2001-07-20 20:59:14 UTC
Personally I suspect that 1048576035 is a pointer to the value the program intended to pass.

Comment 3 Daniel Morris 2001-07-23 16:15:00 UTC
I doubt that the truncate issue is pointer related, the stat64 call
returns the max file size of the system, the truncate tries to allocate
an extra 35 bytes. On my other functional systems, the file is 34 bytes
in length (so 34 + 1 for non-existent NULL grabbed).

Also note that the duplicate in 49386 has the same symptoms, but with
a greatly different file size limit.

Clearly something wacky is going on, as I'd have needed to su 29,959,315 
in three weeks at 35 bytes a time to hit the limit!

 Daniel

Comment 4 John Dalbec 2001-07-26 13:30:20 UTC
*tsk* Uninitialized variables ;-)
In mangle_refcount you have
if (cookie) a.size = <something reasonable>;
but pam_sm_close_session calls mangle_refcount with cookie==NULL so a.size is uninitialized.
I recommend
if (cookie) a.size = <something reasonable>; else a.size = 0;


Comment 5 John Dalbec 2001-07-27 13:06:43 UTC
Created attachment 25147 [details]
This patch fixed the problem for me.  I added it to the SPEC file with -p1.

Comment 6 John Dalbec 2001-07-27 13:18:57 UTC
Daniel:  you probably figured this out, but removing the "unix:0" file should
let you su again.  The patch I supplied only fixes the uncontrolled growth you
observed and will not restore the ability to su (from X, that is) until you
remove this file.

Comment 7 Shaun Durnan 2001-08-28 14:01:59 UTC
I also had this problem.

Bastille firewall introduced a file size limit

I made the same patch to PAM 

This works for me too, ( after removing unix:0)

my question is , when can we expect an update to PAM ?

Comment 8 Nalin Dahyabhai 2001-10-31 20:36:12 UTC
This has been difficult to reproduce, but it should be fixed in pam-0.75-16 (in
7.2 updates) and later.  Can you check if this fixes the problem?

Comment 9 John Dalbec 2001-11-01 13:41:55 UTC
pam-0.75-16 fixes the problem here.

Comment 10 Nalin Dahyabhai 2002-03-08 00:13:38 UTC
Closing.


Note You need to log in before you can comment on or make changes to this bug.