Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1
On Mon, Sep 09, 2019 at 11:14:50PM +0200, John Paul Adrian Glaubitz wrote: > On 9/9/19 10:49 PM, John Paul Adrian Glaubitz wrote: > > 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: > > To reproduce, one can simply run debootstrap with qemu-user-static installed > and > enter the chroot: > > root@epyc:/local_scratch> debootstrap --no-check-gpg --arch=alpha --foreign > --variant=minbase unstable sid-alpha-sbuild > http://ftp.ports.debian.org/debian-ports > (...) > root@epyc:/local_scratch> chroot sid-alpha-sbuild > bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) > I have no name!@epyc:/local_scratch> ./debootstrap/debootstrap --second-stage > E: debootstrap can only run as root > I have no name!@epyc:/local_scratch> > > I assume this would also work on qemu-system-alpha although I haven't tried > yet. But it should work the same way but without the "--foreign" argument. What kernel are you running? Be aware that recent kernels on alpha (since ecf7e0a4ad15287) now support the getuid and getgid syscalls that the other arches always have had. I wonder if glibc has been updated in anyway for that? If so, it should be checking kernel version as to whether to use OSF1 syscall conventions or Linux syscall conventions. OSF1 calling conventions should work on any kernel, whereas Linux calling conventions only on kernels since v5.1. Cheers Michael.
Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1
On Mon, Sep 09, 2019 at 10:49:48PM +0200, John Paul Adrian Glaubitz wrote: > Shortly after typing "root" and pressing enter, the following message is > printed to the > console which seems to be an alpha-specific syscall: > > [ 195.414939] do_entUnaUser: 7 callbacks suppressed No, that is not a syscall, that's the misaligned access by user space interrupt vector letting you know the kernel fixed up 7 misaligned memory accesses. Cheers, Michael.
Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1
Hi! On 9/10/19 10:52 AM, Michael Cree wrote: I assume this would also work on qemu-system-alpha although I haven't tried yet. But it should work the same way but without the "--foreign" argument. What kernel are you running? Be aware that recent kernels on alpha (since ecf7e0a4ad15287) now support the getuid and getgid syscalls that the other arches always have had. I wonder if glibc has been updated in anyway for that? If so, it should be checking kernel version as to whether to use OSF1 syscall conventions or Linux syscall conventions. OSF1 calling conventions should work on any kernel, whereas Linux calling conventions only on kernels since v5.1. 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. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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-al...@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
| 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
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
aurel...@aurel32.net http://www.aurel32.net
Bug#700472: Upgrade of the foreign arch libc6 causes service restart
On 2019-09-09 22:18, Sven Joachim wrote: > Control: tags -1 + patch > > On 2013-02-13 06:20 +0600, Andrey Rahmatullin wrote: > > > Package: libc6 > > Version: 2.17-0experimental2 > > Severity: wishlist > > > > Filing as wishlist, maybe it's minor or even worse for some people. > > > > The postinst script of libc6 checks services that need to be restarted not > > taking into account that those services may be of a different arch and so > > not > > using the libc6 being upgraded. That also means when you upgrade both > > libc6:amd64 and libc6:i386 you get double restart of all those services. > > Today, upgrading libc6:amd64 and libc6:i386 to 2.29-1, I got annoyed by > this again and had a look what needs to be done. The attached patch > (lightly tested, I have only a few amd64 and no i386 services running) > appears to do the trick. It also drops the need for awk in the > maintainer scripts. > > Feedback and brave testers welcome! Thanks for the patch, I have just applied it. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Processed: bug 939898 is forwarded to https://sourceware.org/bugzilla/show_bug.cgi?id=24986
Processing commands for cont...@bugs.debian.org: > forwarded 939898 https://sourceware.org/bugzilla/show_bug.cgi?id=24986 Bug #939898 [src:glibc] glibc: setuid/getuid broken on alpha with 2.29-1 Set Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=24986'. > thanks Stopping processing here. Please contact me if you need assistance. -- 939898: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939898 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#939898: glibc: new getegid, geteuid and getppid syscalls used unconditionally on alpha
Processing control commands: > retitle -1 glibc: new getegid, geteuid and getppid syscalls used > unconditionally on alpha Bug #939898 [src:glibc] glibc: setuid/getuid broken on alpha with 2.29-1 Changed Bug title to 'glibc: new getegid, geteuid and getppid syscalls used unconditionally on alpha' from 'glibc: setuid/getuid broken on alpha with 2.29-1'. -- 939898: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939898 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1
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 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Git][glibc-team/glibc][sid] Do not restart services of different architecture than libc
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc Commits: 366c3309 by Sven Joachim at 2019-09-10T11:15:57Z Do not restart services of different architecture than libc Only check services in packages which are of the same architecture, or arch:all. This is most easily done by replacing the rather convoluted way of parsing dpkg --status output by switching to a more suitable output format of dpkg-query. As a bonus, awk is no longer used in the maintscripts. Note that services in architecture-independent packages like postgresql-common will still be restarted twice, since there is no obvious way to tell the architecture of the actual binaries which need to be re-executed. - - - - - 2 changed files: - debian/changelog - debian/script.in/nsscheck.sh View it on GitLab: https://salsa.debian.org/glibc-team/glibc/commit/366c3309c1907a34a58a24dee4805e57fc60c5a9 -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/commit/366c3309c1907a34a58a24dee4805e57fc60c5a9 You're receiving this email because of your account on salsa.debian.org.
Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1
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. I am not sure this is an glibc issue in this case.
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 aurel...@aurel32.net http://www.aurel32.net
[Git][glibc-team/glibc][sid] patches/hurd-i386/submitted-anon-mmap-shared.diff: Re-disable
Samuel Thibault pushed to branch sid at GNU Libc Maintainers / glibc Commits: 43c69fdb by Samuel Thibault at 2019-09-10T21:23:57Z patches/hurd-i386/submitted-anon-mmap-shared.diff: Re-disable actually makes some tests fail - - - - - 2 changed files: - debian/changelog - debian/patches/series View it on GitLab: https://salsa.debian.org/glibc-team/glibc/commit/43c69fdb52c3287e3f7aba40e2ac679e0195e59d -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/commit/43c69fdb52c3287e3f7aba40e2ac679e0195e59d You're receiving this email because of your account on salsa.debian.org.
