Bug 1983443

Having a look at test-user-util.c, around line 382 :
 
static void test_in_gid(void) {
        assert(in_gid(getgid()) >= 0);
        assert(in_gid(getegid()) >= 0);        assert(in_gid(TTY_GID) == 0); /* The TTY gid is for owning ttys, it would be really really weird if we were in it. */
}

I guess I'm in the 'really really weird' category here ?

What do I do when I'm 'in it' (to get out of it) ?

My userid is '666', group '666', groups:
666(devel),3(sys),5(tty),6(disk),7(lp),8(mem),9(kmem),10(wheel),11(cdrom),19(floppy),29(rpcuser),33(tape),39(video),54(lock),63(audio),100(users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

It looks to me like the extra 'really really weird' 
   assert(in_gid(TTY_GID) == 0) 
should be removed.

This is when running under bash-5.1.8(1)-release, a newer bash version than standard.

If we had a controlling TTY, and were in the setpgid() group, wouldn't it be 'really really weird'
if in_gid(TTY_GID) was not true ?

Created attachment 1803032 [details]
Patch to test-user-util.c to remove offending assert() .

Patch to test-user-util.c to remove offending assert() .

diff -up systemd-stable-248.4/src/test/test-user-util.c~ systemd-stable-248.4/src/test/test-user-util.c
--- systemd-stable-248.4/src/test/test-user-util.c~	2021-07-12 12:38:53.000000000 +0100
+++ systemd-stable-248.4/src/test/test-user-util.c	2021-07-18 17:10:29.912449545 +0100
@@ -379,7 +379,7 @@ static void test_make_salt(void) {
 
 static void test_in_gid(void) {
         assert(in_gid(getgid()) >= 0);
-        assert(in_gid(getegid()) >= 0);        assert(in_gid(TTY_GID) == 0); /* The TTY gid is for owning ttys, it would be really really weird if we were in it. */
+        assert(in_gid(getegid()) >= 0); //       assert(in_gid(TTY_GID) == 0); /* The TTY gid is for owning ttys, it would be really really weird if we were in it. */
 }
 
 static void test_gid_lists_ops(void) {


--- SPECS/systemd.spec~	2021-07-12 13:25:00.000000000 +0100
+++ SPECS/systemd.spec	2021-07-18 17:17:11.664625748 +0100
@@ -22,5 +22,5 @@
 Url:            https://www.freedesktop.org/wiki/Software/systemd
 Version:        248.4
-Release:        1%{?dist}
+Release:        2%{?dist}
 # For a breakdown of the licensing, see README
 License:        LGPLv2+ and MIT and GPLv2+
@@ -85,4 +85,6 @@
 Patch0501:      https://github.com/systemd/systemd/pull/17050/commits/f58b96d3e8d1cb0dd3666bc74fa673918b586612.patch
 
+Patch0666:      systemd-248.4-test-user-util.patch
+
 %ifarch %{ix86} x86_64 aarch64
 %global have_gnu_efi 1
@@ -474,5 +476,6 @@
         # https://bugzilla.redhat.com/show_bug.cgi?id=1867830
         -Ddefault-mdns=no
-        -Ddefault-llmnr=resolve
+        -Ddefault-llmnr=no
+	# resolve
         -Doomd=true
 )
@@ -975,4 +978,7 @@
 
 %changelog
+* Sun Jul 18 2021 Jason Vas Dias <jason.vas.dias> - 248.4-2
+- Fix Bug 1983443
+
 * Mon Jul 12 2021 Zbigniew Jędrzejewski-Szmek <zbyszek.pl> - 248.4-1
 - Assorted fixes (some systemd-resolved crashes, invalid

Created attachment 1803033 [details]
Patch to systemd.spec

Patch to systemd.spec to apply the test-user-util.c fix,
and to not make 'resolve' the 'default-llmnr' (bug 1983432).

Hmm, now with that change I still get a build test failure:

The output from the failed tests:

331/617 test-repart                               FAIL           0.08s (exit status 1)

--- command ---
16:21:49 /home/jvd/rpmbuild/BUILD/systemd-stable-248.4/src/partition/test-repart.sh /home/jvd/rpmbuild/BUILD/systemd-stable-248.4/x86_64-redhat-linux-gnu/systemd-repart
--- stdout ---
### Testing systemd-repart --empty=create ###
--- stderr ---
+ [[ -e /dev/loop-control ]]
+ repart=/home/jvd/rpmbuild/BUILD/systemd-stable-248.4/x86_64-redhat-linux-gnu/systemd-repart
+ test -x /home/jvd/rpmbuild/BUILD/systemd-stable-248.4/x86_64-redhat-linux-gnu/systemd-repart
++ mktemp --tmpdir --directory test-repart.XXXXXXXXXX
+ D=/tmp/test-repart.vpxHpruSQk
+ trap 'rm -rf '\''/tmp/test-repart.vpxHpruSQk'\''' EXIT INT QUIT PIPE
+ mkdir -p /tmp/test-repart.vpxHpruSQk/definitions
+ SEED=e2a40bf9-73f1-4278-9160-49c031e7aef8
+ echo '### Testing systemd-repart --empty=create ###'
+ /home/jvd/rpmbuild/BUILD/systemd-stable-248.4/x86_64-redhat-linux-gnu/systemd-repart /tmp/test-repart.vpxHpruSQk/zzz --empty=create --size=1G --seed=e2a40bf9-73f1-4278-9160-49c031e7aef8
Sized '/tmp/test-repart.vpxHpruSQk/zzz' to 1.0G.
Applying changes.
Wiped block device.
Discarded entire block device.
Writing new partition table.
All done.
+ grep -v -e sector-size -e '^$'
+ sfdisk -d /tmp/test-repart.vpxHpruSQk/zzz
/home/jvd/rpmbuild/BUILD/systemd-stable-248.4/src/partition/test-repart.sh: line 20: sfdisk: command not found
+ rm -rf /tmp/test-repart.vpxHpruSQk
-------


Summary of Failures:

324/617 udev-test                                 SKIP           0.07s
331/617 test-repart                               FAIL           0.08s (exit status 1)
371/617 test-sd-device-monitor                    SKIP           0.01s
382/617 test-dhcp-server                          SKIP           0.12s
398/617 test-oomd-util                            SKIP           0.07s
411/617 test-chown-rec                            SKIP           0.01s
416/617 test-boot-timestamps                      SKIP           0.01s
423/617 test-dev-setup                            SKIP           0.01s
424/617 test-capability                           SKIP           0.01s
479/617 test-barrier                              SKIP           0.02s
481/617 test-namespace                            SKIP           0.26s
488/617 test-loop-block                           SKIP           0.04s
491/617 test-bpf-devices                          SKIP           0.03s
492/617 test-bpf-firewall                         SKIP           0.05s
493/617 test-watch-pid                            SKIP           0.03s
512/617 test-firewall-util                        SKIP           0.02s
535/617 test-execute                              SKIP           0.04s

Ok:                 600 
Expected Fail:      0   
Fail:               1   
Unexpected Pass:    0   
Skipped:            16  
Timeout:            0   


I guess I'll have to file a new bug report on that.

Created attachment 1803046 [details]
Patch to systemd.spec

systemd.spec fixes also Bug 1983443, Bug 1983450

Ok, with last attached systemd.spec patch applied, systemd now builds OK.

> My userid is '666', group '666', groups:
> 666(devel),3(sys),5(tty),6(disk),7(lp),8(mem),9(kmem),10(wheel),11(cdrom),19(floppy),29(rpcuser),33(tape),39(video),54(lock),63(audio),100(users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Eh, that just means your user is very strangely set up. The user that is used for building packages
certainly shouldn't have the ability to write to raw disk devices (group disk), or access kernel
memory (kmem), etc.


Sorry, but your setup is borked and the patch doesn't really have anything to do with the issue.

RE: 
  >> your setup is borked
I will be the judge of that, thanks - 
the only problem found so far is being
unable to build systemd because the test suite
fails with the test-user-util.c assert shown,
which the patch ( systemd-248-4-test-user-util.patch )
does in fact fix.
 ( in_gid(TTY_GID) != 0 ) .

RE:
>> the patch doesn't really have anything to do with the issue.
 Actually, the patch does - systemd is able to build
 with the test-user-util.c patch, and is unable to build without it -
also the additional systemd.spec patches are necessary to enable
building .

And also, my userid's group memberships are not relevant to this bug.
Why should the success of the test suite depend on the group memebership
of whatever user happens to be building the RPM ?
That assertion : 
    'in_gid(TTY_GID) == 0'
fails because my userid is in the 'tty' group.
But that has no relevance to the test.
Or maybe that test has to be skipped if the
user is in the 'tty' group.
Or maybe the .spec file should test if the user
is in the 'tty' group and refuse to build if so -
I can't see why you'd want to do that.
But please, allow users who are in the tty group
to build ! Why make unecessary restrictions on
who can build the RPM?

Please don't reopen the bug. I'm NOT telling you to fix your setup, only that there's nothing
to fix in the rpm.