From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 Description of problem: I've been debugging another massive fall-apart at my site :-( This is current Samba HEAD, so I suspected a Samba bug, but it also failed on my backup machine, running a much older version, and worked again when glibc downgraded.. ----- This time it appears that the installation of glibc=2.3.2-4.80.i686.rpm (required to fix a security issue) broke my installation. It appears that it would *occasionally* cause setresuid() to fail. Most of the time it would work - particularly during the configure. However during actual use, it seems to fail - samba does not accept this, and asserts. On downgrading to RH 8.0 release glibc, things returned to normal. Catching one in GDB *seems* to suggest that the errno might be EINVAL. Mar 24 09:51:28 kate smbd[31962]: [2003/03/24 09:51:28, 0] lib/util_sec.c:assert_uid(95) Mar 24 09:51:28 kate smbd[31962]: Failed to set uid privileges to (-1,65773) now set to (0,0) Mar 24 09:51:28 kate smbd[31962]: [2003/03/24 09:51:28, 0] lib/util.c:smb_panic(1419) Mar 24 09:51:28 kate smbd[31962]: smb_panic(): calling panic action [/etc/samba/panic-action 31962] My panic-action didn't work properly however, which is annoying me :-(. Interestingly, earlier in the day I had these errors - I'm not on NFS. (this is the same errno). But it could just as easily be more generic locking bugs... Mar 24 11:20:00 kate smbd[23560]: [2003/03/24 11:20:00, 0] locking/posix.c:posix_fcntl_lock(658) Mar 24 11:20:00 kate smbd[23560]: posix_fcntl_lock: WARNING: lock request at offset 0, length 1024 returned Mar 24 11:20:00 kate smbd[23560]: [2003/03/24 11:20:00, 0] locking/posix.c:posix_fcntl_lock(659) Mar 24 11:20:00 kate smbd[23560]: an Invalid argument error. This can happen when using 64 bit lock offsets Mar 24 11:20:00 kate smbd[23560]: [2003/03/24 11:20:00, 0] locking/posix.c:posix_fcntl_lock(660) Mar 24 11:20:00 kate smbd[23560]: on 32 bit NFS mounted file systems. Anybody got any ideas? Or anybody had similar problems? Even if it's a glibc bug, we probably need to detect/work around it. It appears that setresuid() is an 'odd' call - is there a better one to call? Andrew Bartlett Version-Release number of selected component (if applicable): 2.3.2-4.80 How reproducible: Sometimes Steps to Reproduce: 1. Upgrade glibc to security release 2. Wait for a large number of connections 3. Wait for some to panic Actual Results: Samba panics, becouse setresuid() failed to change the UID Expected Results: Samba should never get an error from setresuid() Additional info: This is Samba HEAD, so I don't expect sympathy, but it does look like a real bug in glibc. This is not reproduced for the simple test-case in configure. This makes it hard for Samba to automaticly work around :-(
Can you attach ltrace output around the failures for both 2.2.93-5 and 2.3.2-4.80 or (even better) create small testcases what's samba actually doing with these functions so that they fail? glibc can be fixed if there is a bug in it, or samba can be fixed if the bug is there.
I'm pretty sure it's not a Samba bug - I've inpspected the calls and the manpage, and it's all within spec. The problem is the testcases :-( This occoured on my production server, but I've not seen it otherwise. For the failure above, the args would have been setresuid(-1, 65773, -1). Andrew Bartlett
There are two things. One is a kernel bug which causes /lib/libc.so.6 not /lib/i686/libc.so.6 to be used. The other is a glibc bug when 32-bit uid support in the kernel cannot be assumed: http://sources.redhat.com/ml/libc-alpha/2003-03/msg00468.html http://sources.redhat.com/ml/libc-alpha/2003-03/msg00469.html
Can you try ftp://people.redhat.com/jakub/glibc/errata/8.0/ (both without LD_ASSUME_KERNEL in the environment and with LD_ASSUME_KERNEL=2.2.5 in samba's environment)?
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2003-136.html
Is RedHat intending to issue and 8.0 errata for this? The errata only contains references to 9. Thanks,
It has been issued quite some time ago already. See https://rhn.redhat.com/errata/RHSA-2003-089.html