Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1
On 2019-09-09 23:16, Aurelien Jarno wrote:
> On 2019-09-09 22:49, John Paul Adrian Glaubitz wrote:
> > Source: glibc
> > Version: 2.29-1
> > Severity: important
> > User: debian-alpha@lists.debian.org
> > Usertags: alpha
> >
> > Hello!
> >
> > Both on my Alpha XP-1000 as well as inside a qemu-user chroot, upgrading glibc
> > to version 2.29-1 resulted in setuid/getuid breaking in a weird way:
>
> As a side note, I have successfully upgrade a qemu-system-alpha based
> machine without issue. It actually fixes long standing issues with
> systemd. The VM runs kernel 5.2.0-2-alpha-smp.
The problem happens when running with kernel < 5.1. The problem is not
directly related to the new upstream version, but rather to the fact
that the glibc has been built against new kernel headers, which include
the following changes:
| commit ecf7e0a4ad1528710c90f0a6f4285741ac525f6e
| Author: Arnd Bergmann <arnd@arndb.de>
| Date: Fri Jan 11 15:09:11 2019 +0100
|
| alpha: add generic get{eg,eu,g,p,u,pp}id() syscalls
|
| Alpha has traditionally followed the OSF1 calling conventions
| here, with its getxpid, getxuid, getxgid system calls returning
| two different values in separate registers.
|
| Following what glibc has done here, we can define getpid,
| getuid and getgid to be aliases for getxpid, getxuid and getxgid
| respectively, and add new system call numbers for getppid, geteuid
| and getegid.
|
| Signed-off-by: Arnd Bergmann <arnd@arndb.de>
With this change the new syscalls are being used by the glibc instead of
the old OSF1 ones. However they do not exist on kernels < 5.1 so things
break.
The short term solution is to upgrade the kernel to > 5.1. The long term
solution is to write a wrapper on the glibc side to fallback on the old
syscalls if the new ones do not exist.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: