[DSE-Dev] Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude

[Laurent Bigonville]

Le 26/01/21 à 13:44, Julian Andres Klode a écrit :
> On Tue, Jan 26, 2021 at 12:52:52PM +0100, Aurelien Jarno wrote:
>> reassign 979970 src:glibc,src:libselinux,src:apt,src:openssh
>> thanks
>>
>> On 2021-01-25 11:59, Laurent Bigonville wrote:
>>> reassign 979970 src:glibc 2.30-1
>>> affects 979970 + libselinux1
>>> thanks
>>>
>>> On Tue, 12 Jan 2021 13:31:19 +0100 Charlemagne Lasse
>>> <charlemagnelasse at gmail.com> wrote:
>>>
>>>> Right now, an update from buster to bullseye on amd64 completely
>>>> bricks the system because libselinux1 is requiring a libc6 which is
>>>> not yet installed on the system:
>>>>
>>>> Preparing to unpack .../0-libselinux1_3.1-2+b2_amd64.deb ...
>>>> De-configuring libselinux1:i386 (2.8-1+b1) ...
>>>> Unpacking libselinux1:amd64 (3.1-2+b2) over (2.8-1+b1) ...
>>>> tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not
>>>> found (required by /lib/x86_64-linux-gnu/libselinux.so.1)
>>>> dpkg-deb: error: tar subprocess returned error exit status 1
>>>>
>>>> It is then not possible anymore to recover the system because dpkg
>>>> (mv, ...) is no longer working.
>>>>
>>>> There is most likely some kind dependency missing to let aptitude
>>>> known that it must first update libc6 before it can update
>>>> libselinux1. At least on this system, the installed version of libc6
>>>> for amd64 and i386 was still 2.28-10 when this happened
>>> After some discussion on IRC it looks like the problem is apparently coming
>>> from the breaks added to the libc6 package.
>> The break hasn't been added randomly, but in response to upstream
>> release notes and bug #965932. In short the openssh seccomp filters in
>> buster are too narrow, and do not allow the new 64-bit syscalls needed
>> for 64-bit time_t compatibility to be used.
>>
>> So we definitely can't drop this break. For me this is not a libc6 bug.
>> Or if it is, it is as much the fault of libc6 (for using new syscalls)
>> than libselinux1 (for starting using symbol versioning).
> This is not a question of finding the right solution, but more of the
> least worst one.
>
The reason that libselinux needs glibc >= 2.30 is because it now uses 
gettid(), it cas be replaced by syscall(__NR_gettid), right?

With the following patch, the dependency is back to "Depends: libc6 (>= 
2.14), libpcre2-8-0 (>= 10.22)" at least on amd64

--- a/src/procattr.c
+++ b/src/procattr.c
@@ -94,7 +94,7 @@ static int openattr(pid_t pid, const cha
  		if (fd >= 0 || errno != ENOENT)
  			goto out;
  		free(path);
-		tid = gettid();
+		tid = syscall(__NR_gettid);
  		rc = asprintf(&path, "/proc/self/task/%d/attr/%s", tid, attr);
  	} else {
  		errno = EINVAL;

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/selinux-devel/attachments/20210128/36d66cbc/attachment.html>