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
*** Bug 49386 has been marked as a duplicate of this bug. ***
Personally I suspect that 1048576035 is a pointer to the value the program intended to pass.
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
*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;
Created attachment 25147 [details] This patch fixed the problem for me. I added it to the SPEC file with -p1.
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.
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 ?
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?
pam-0.75-16 fixes the problem here.
Closing.