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

Bug#939898: glibc: new getegid, geteuid and getppid syscalls used unconditionally on alpha



control: retitle -1 glibc: new getegid, geteuid and getppid syscalls used unconditionally on alpha

On 2019-09-10 09:27, Adhemerval Zanella wrote:
> 
> 
> On 10/09/2019 07:28, John Paul Adrian Glaubitz wrote:
> > On 9/10/19 11:05 AM, John Paul Adrian Glaubitz wrote:
> >> Yes, we have already figured out that this happens when the kernel is
> >> too old. According to Aurelien, the problem is that the glibc package
> >> has been built against the kernel 5.3 headers which is why users need
> >> to upgrade their kernel first before upgrading glibc.
> >>
> >> Currently fixing tsunami.
> > 
> > I have now kernel 5.2.9-1 and glibc 2.29-1 and logging in still doesn't
> > work. I type "root" at the login prompt, press enter and it shortly
> > returns to the login prompt. Logging in through SSH doesn't work either.
> > 
> > Adrian
> > 
> 
> I have consolidate the set* Linux implementations on dd5905de03bd2 
> (glibc 2.26), which means that all Linux architectures should use
> sysdeps/unix/sysv/linux/setuid.c for setuid and the auto-generated
> syscalls for getuid.
> 
> Alpha use the linux generic implementation since ever, the 
> dd5905de03bd2 change it will prioritize to use __NR_setuid32 instead
> of __NR_setuid. But since it is not the case for alpha AFAIK it should
> not change the code generation. I also checked that the code for
> setuid for both glibc 2.25 and glibc 2.31 hasn't change, it issues the
> __NR_setuid (23) for both cases.

The title of the bug is actually misleading, only getegid, geteuid and
getppid are affected. Let's retitle the bug accordingly.

> I am not sure this is an glibc issue in this case.

This is actually glibc issue, see:
https://sourceware.org/bugzilla/show_bug.cgi?id=24986
https://www.sourceware.org/ml/libc-alpha/2019-09/msg00152.html

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: