[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#182386: marked as done (libc6: setegid on i386 uses setregid and therefore sets saved gid)

Your message dated Wed, 11 Apr 2007 00:10:30 +0200
with message-id <20070410221030.GA4506@artemis>
and subject line Bug#182386: libc6: setegid on i386 uses setregid and therefore sets saved gid
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: libc6
Version: 2.3.1-13
Severity: normal

*** Please type your report below this line ***

One of the LTP tests (setresgid02) was failing on PPC64 and succeeding on
I386 and it turns out that the test makes the assumption that setegid()
sets the saved gid as well as the effective gid.  According to the POSIX.1
2001 (SUSv3) setegid should not change the saved gid.  On i386 setegid()
is currently using setregid32() at the system call level while on ppc64
it uses setresgid().  In the glibc sources, it appears that setegid()
should be using setresgid() on i386, but strace/ltrace shows otherwise.

The setegid manual page actually says:

       Under  libc4,  libc5  and  glibc2.0  seteuid(euid)  is equivalent
       to setreuid(-1,	euid)  and    hence  may  change  the saved user
       ID.  Under glibc2.1 it is equivalent to setresuid(-1, euid,-1)
       and hence does  not change the saved user ID.  Similar remarks
       hold for setegid.

I am not sure if this is just a bug in the way glibc is built for i386,
or some strange interaction with the headre files.


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux elm 2.4.19-pre8 #1 Wed May 8 15:38:14 EST 2002 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages libc6 depends on:
ii  libdb1-compat                 2.1.3-7    The Berkeley database routines [gl

-- no debconf information


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

--- End Message ---
--- Begin Message --- 
Version: 2.5

  It's maybe even fixed in etch, I'm too lazy to check. But with
experimental glibc, ltrace and strace show that the correct syscall is
used now.

On Tue, Feb 25, 2003 at 12:51:16PM +1100, Stephen Rothwell wrote:
> Package: libc6
> Version: 2.3.1-13
> Severity: normal
> 
> *** Please type your report below this line ***
> 
> One of the LTP tests (setresgid02) was failing on PPC64 and succeeding on
> I386 and it turns out that the test makes the assumption that setegid()
> sets the saved gid as well as the effective gid.  According to the POSIX.1
> 2001 (SUSv3) setegid should not change the saved gid.  On i386 setegid()
> is currently using setregid32() at the system call level while on ppc64
> it uses setresgid().  In the glibc sources, it appears that setegid()
> should be using setresgid() on i386, but strace/ltrace shows otherwise.
> 
> The setegid manual page actually says:
> 
>        Under  libc4,  libc5  and  glibc2.0  seteuid(euid)  is equivalent
>        to setreuid(-1,	euid)  and    hence  may  change  the saved user
>        ID.  Under glibc2.1 it is equivalent to setresuid(-1, euid,-1)
>        and hence does  not change the saved user ID.  Similar remarks
>        hold for setegid.
> 
> I am not sure if this is just a bug in the way glibc is built for i386,
> or some strange interaction with the headre files.
> 
> 
> -- System Information:
> Debian Release: testing/unstable
> Architecture: i386
> Kernel: Linux elm 2.4.19-pre8 #1 Wed May 8 15:38:14 EST 2002 i686
> Locale: LANG=C, LC_CTYPE=C
> 
> Versions of packages libc6 depends on:
> ii  libdb1-compat                 2.1.3-7    The Berkeley database routines [gl
> 
> -- no debconf information
> 
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> 

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgp2gSl05ofmo.pgp
Description: PGP signature


--- End Message ---
Reply to: