Bug 86534 - RedHat's glibc-2.3.2 and Samba -> assert_uid() failures?
Summary: RedHat's glibc-2.3.2 and Samba -> assert_uid() failures?
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 8.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-25 09:54 UTC by Andrew Bartlett
Modified: 2016-11-24 14:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-09 19:21:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2003:136 high SHIPPED_LIVE glibc bugfix errata 2003-04-09 04:00:00 UTC
Red Hat Product Errata RHSA-2003:089 high SHIPPED_LIVE : Updated glibc packages fix vulnerabilities in RPC XDR decoder 2003-04-10 04:00:00 UTC

Description Andrew Bartlett 2003-03-25 09:54:22 UTC
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 :-(

Comment 1 Jakub Jelinek 2003-03-25 10:01:29 UTC
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.

Comment 2 Andrew Bartlett 2003-03-25 10:07:45 UTC
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


Comment 3 Jakub Jelinek 2003-03-26 15:02:33 UTC
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

Comment 4 Jakub Jelinek 2003-03-26 17:42:52 UTC
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)?

Comment 5 Jakub Jelinek 2003-04-09 19:21:32 UTC
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


Comment 6 Andrew Bartlett 2003-04-25 15:22:21 UTC
Is RedHat intending to issue and 8.0 errata for this?  The errata only contains
references to 9.

Thanks,

Comment 7 Jakub Jelinek 2003-04-25 15:29:54 UTC
It has been issued quite some time ago already. See
https://rhn.redhat.com/errata/RHSA-2003-089.html


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