Requests for -current (14.2-->15.0)

RadicalDreamer · 01-23-2022, 04:44 PM

Code:

NOTE: Some installed or upgraded package may need reboot: 
           kernel-huge-5.15.16-x86_64-1
           kernel-generic-5.15.16-x86_64-1
See /var/run/needs_restarting for details

I don't think rebooting is a good message to send someone that just updated kernels. How about run liloconfig for MBR, and eliloconfig for UEFI instead if the kernel is updated before rebooting?

Also I think the UPGRADE.txt should explain why and how to remove .la files. http://ftp.slackware.com/pub/slackwa...nt/UPGRADE.TXT

LuckyCyborg · 01-23-2022, 04:56 PM

Quote:

Originally Posted by RadicalDreamer

Code:

NOTE: Some installed or upgraded package may need reboot: 
           kernel-huge-5.15.16-x86_64-1
           kernel-generic-5.15.16-x86_64-1
See /var/run/needs_restarting for details

I don't think rebooting is a good message to send someone that just updated kernels. How about run liloconfig for MBR, and eliloconfig for UEFI instead if the kernel is updated before rebooting?

How about to abandon those ancient technologies used by Tutankhamen when he built piramides and just to use the modern Grub2 ?

Grub2 is smart enough to not need additional liloconfig/eliloconfig runs, assuming that an eventual initrd is properly generated in place.

I remember that years ago here was an user who said many times: do not complicate your life in the name of simplicity!

RadicalDreamer · 01-23-2022, 05:22 PM

Quote:

Originally Posted by LuckyCyborg

How about to abandon those ancient technologies used by Tutankhamen when he built piramides and just to use the modern Grub2 ?

Grub2 is smart enough to not need additional liloconfig/eliloconfig runs, assuming that an eventual initrd is properly generated in place.

I remember that years ago here was an user who said many times: do not complicate your life in the name of simplicity!

I'm happy with those old technologies because I'm dumb enough to understand them. Grub2 is fine but I think that could wait till 15.1 development cycle. My issue is that slackpkg is encouraging people who don't know any better to reboot to a borked system after a kernel update. I just recycle the lilo on my laptop with liloconfig which is easy. I copy updated vmlinuz and initrd.gz to my efi partition on my PC because using eliloconfig sometimes breaks efibootmgr so I can't specify boot order, and I have to wait until the next kernel update for it to fix itself. I have no idea why that happens but updating the system isn't hard.

peake · 01-23-2022, 06:12 PM

Quote:

Originally Posted by volkerdi

The Plan 9 filesystem driver is already built into the huge kernel.

Plan 9 networking support is, but not the filesystem driver:

Code:

$ grep '9P' config-huge-5.15.16
CONFIG_NET_9P=y <---Networking support---
CONFIG_NET_9P_VIRTIO=y
CONFIG_NET_9P_RDMA=m
# CONFIG_NET_9P_DEBUG is not set
CONFIG_VIDEO_MT9P031=m
CONFIG_9P_FS=m <---Filesystem driver---
# CONFIG_9P_FSCACHE is not set
CONFIG_9P_FS_POSIX_ACL=y
# CONFIG_9P_FS_SECURITY is not set

Jan K. · 01-23-2022, 06:40 PM

Quote:

Originally Posted by LuckyCyborg

How about to abandon those ancient technologies used by Tutankhamen when he built piramides and just to use the modern Grub2 ?

They are still standing and running just fine.

Dived into the grub manual for a while and decided simpler is better... Lilo and eLilo fits very well.

reFind would be an interesting add-on, though.

camerabambai · 01-23-2022, 08:53 PM

Why not to add/enable those options on kernel for Xen paravirt domU?

Code:

CONFIG_XEN=y
CONFIG_XEN_PV=y
CONFIG_XEN_PV_SMP=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_PVHVM_SMP=y
CONFIG_XEN_512GB=y
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_XEN_SCSI_FRONTEND=y
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES_DEFAULT=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PRIVCMD=y
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_XEN_EFI=y
CONFIG_XEN_AUTO_XLATE=y
CONFIG_XEN_ACPI=y
CONFIG_XEN_SYMS=y
CONFIG_XEN_HAVE_VPMU=y

actually kernel-generic of Slackware-current has those options enabled

Code:

zgrep -i xen /proc/config.gz 
# CONFIG_XEN is not set
CONFIG_KVM_XEN=y
CONFIG_NETXEN_NIC=m
CONFIG_MMC_SDHCI_XENON=m

can boot as domU but in hvm mode(too slow)

marav · 01-23-2022, 08:57 PM

Hopefully, we should be at the very end of this RC3

I think this thread should be closed

camerabambai · 01-23-2022, 09:50 PM

When gpg is invoked for the first time set the server "keys.gnupg.net" as default.
This server is not working anymore, is possible to set a working keyserver as default, so when gpg is invoked for the first time set a good server?

For example:

Code:

keyserver hkps://keyserver.ubuntu.com:443

marav · 01-24-2022, 03:18 AM

Quote:

Originally Posted by camerabambai

When gpg is invoked for the first time set the server "keys.gnupg.net" as default.
This server is not working anymore, is possible to set a working keyserver as default, so when gpg is invoked for the first time set a good server?

For example:

Code:

keyserver hkps://keyserver.ubuntu.com:443

keyservers are apparently hard coded (cf. dirmngr/server.c in source code)

But you can make your own gpg.conf

Code:

$ echo "keyserver hkps://keyserver.ubuntu.com:443" > ~/.gnupg/gpg.conf

chrisretusn · 01-24-2022, 05:43 AM

Quote:

Originally Posted by RadicalDreamer

Code:

NOTE: Some installed or upgraded package may need reboot: 
           kernel-huge-5.15.16-x86_64-1
           kernel-generic-5.15.16-x86_64-1
See /var/run/needs_restarting for details

I don't think rebooting is a good message to send someone that just updated kernels. How about run liloconfig for MBR, and eliloconfig for UEFI instead if the kernel is updated before rebooting?

Also I think the UPGRADE.txt should explain why and how to remove .la files. http://ftp.slackware.com/pub/slackwa...nt/UPGRADE.TXT

Before that message is displayed, this one is shown.

Code:

Your kernel image was updated, and your /etc/lilo.conf indicates
the use of an initrd for at least one of your kernels. Be sure to
regenerate the initrd for the new kernel and handle any needed
updates to your bootloader.

Press the "Enter" key to continue...

MDKDIO · 01-24-2022, 06:32 AM

Quote:

Originally Posted by camerabambai

When gpg is invoked for the first time set the server "keys.gnupg.net" as default.
This server is not working anymore, is possible to set a working keyserver as default, so when gpg is invoked for the first time set a good server?

For example:

Code:

keyserver hkps://keyserver.ubuntu.com:443

Would this be an option?

https://keys.openpgp.org/about/usage

And specifically for GnuPG
keyserver hkps://keys.openpgp.org

Just thought I'd ask...

Thom1b · 01-24-2022, 06:50 AM

util-linux-2.37.3 is released with two security fixes:

Quote:

util-linux 2.37.3 Release Notes
===============================

This release fixes two security mount(8) and umount(8) issues:

CVE-2021-3996
Improper UID check in libmount allows an unprivileged user to unmount FUSE
filesystems of users with similar UID.

CVE-2021-3995
This issue is related to parsing the /proc/self/mountinfo file allows an
unprivileged user to unmount other user's filesystems that are either
world-writable themselves or mounted in a world-writable directory.

marav · 01-24-2022, 07:15 AM

Quote:

Originally Posted by almope

I've tried to install -current and this showed up in one of the consoles during setup:

Code:

...
WARN: /usr/bin/sq_ing not present -- please install sg3_utils
or rescan-scsi-bus.sh might not fully work.
Scanning SCSI subsystem for new devices
Scanning host 0 for  SCSI target IDs 0 1 2 3 4 5 6 7, LUNs 0
1
2
3
4
5
6
7
find: unrecognized: -printf
BusyBox v1.32.1 (2022-01-18 14:36:34 CST) multi-call binary.

Usage: find [-HL] [PATH]... [OPTIONS] [ACTIONS]
Search for files and perform ...

Possibly this is expected behavior or BB syntax has changed since the setup application was reviewed.

Seems to be fixed

Code:

Sat Jan 22 21:34:07 UTC 2022
  Reverted to an older simpler version of rescan-scsi-bus that does what we
  need it to on the installer. Apparently the one we upgraded to requires the
  real version of "find" and has additional requirements resulting in it being
  broken for almost a year. Since nobody noticed until now, I wonder to what
  extent this functionality is still important on modern hardware, but we'll
  fix it anyway just in case. Thanks to almope.
  Added sg.ko kernel module (rescan-scsi-bus has always wanted this but never
  previously got it, so we'll add it and hope it helps).

Thom1b · 01-24-2022, 08:20 AM

Two security fixes are available for glibc:

Quote:

Hi all,

We discovered two vulnerabilities in the glibc, CVE-2021-3998 in
realpath() and CVE-2021-3999 in getcwd(). Patches are now available at
(many thanks to Siddhesh Poyarekar and Red Hat Product Security):

https://sourceware.org/git/gitweb.cg...bc907e10aec9bb
https://sourceware.org/git/gitweb.cg...eb0d26423e04e5

https://sourceware.org/git/gitweb.cg...cccdc90c2dcd5e
https://sourceware.org/git/gitweb.cg...a801765fceb39c

Below is a short write-up (which is part of a longer advisory that is
mostly unrelated to the glibc and that we will publish at a later date):

========================================================================
CVE-2021-3998: Unexpected return value from glibc's realpath()
========================================================================

While auditing umount and fusermount, we also discovered a vulnerability
in the glibc's realpath() function, which is used internally by various
programs. Normally, when the output buffer "resolved" that is passed to
realpath() is not NULL, then realpath() either returns NULL on failure,
or it returns the output buffer "resolved" on success. Unfortunately,
since commit c6e0b0b ("stdlib: Sync canonicalize with gnulib") from
January 2021, realpath() can mistakenly return a malloc()ated buffer
that is neither NULL nor the output buffer "resolved":

------------------------------------------------------------------------
430 char *
431 __realpath (const char *name, char *resolved)
432 {
...
437 struct scratch_buffer rname_buffer;
438 return realpath_stk (name, resolved, &rname_buffer);
439 }
------------------------------------------------------------------------
197 static char *
198 realpath_stk (const char *name, char *resolved,
199 struct scratch_buffer *rname_buf)
200 {
...
399 failed = false;
...
403 if (resolved != NULL && dest - rname <= get_path_max ())
404 rname = strcpy (resolved, rname);
...
410 if (failed || rname == resolved)
411 {
412 scratch_buffer_free (rname_buf);
413 return failed ? NULL : resolved;
414 }
415
416 return scratch_buffer_dupfree (rname_buf, dest - rname);
417 }
------------------------------------------------------------------------

For example, if the input path "name" is "." and if the current working
directory is longer than PATH_MAX, then:

- at line 399, "failed" is set to false;

- at lines 403-404, "rname" is NOT set to "resolved" and "resolved" is
left untouched and uninitialized (because "dest - rname" is longer
than PATH_MAX);

- the code block at lines 410-414 is skipped (because "failed" is false
and "rname" is not "resolved");

- at line 416, scratch_buffer_dupfree() returns a malloc()ated buffer
that is NOT the output buffer "resolved".

The consequences of this vulnerability depend on the affected programs;
for example, fusermount (a SUID-root program) can disclose sensitive
information (pointers) when displaying the contents of a stack-based
buffer that is mistakenly left uninitialized by realpath() (we tested
this proof of concept on Ubuntu 21.04):

------------------------------------------------------------------------
$ gcc -o CVE-2021-3998-fusermount CVE-2021-3998-fusermount.c
$ ./CVE-2021-3998-fusermount > CVE-2021-3998-fusermount.output
...

$ hexdump -C CVE-2021-3998-fusermount.output
00000000 2f 75 73 72 2f 62 69 6e 2f 66 75 73 65 72 6d 6f |/usr/bin/fusermo|
00000010 75 6e 74 3a 20 65 6e 74 72 79 20 66 6f 72 20 f0 |unt: entry for .|
00000020 83 9b 99 ff 7f 20 6e 6f 74 20 66 6f 75 6e 64 20 |..... not found |
00000030 69 6e 20 2f 65 74 63 2f 6d 74 61 62 0a 0a 2f 75 |in /etc/mtab../u|
00000040 73 72 2f 62 69 6e 2f 66 75 73 65 72 6d 6f 75 6e |sr/bin/fusermoun|
00000050 74 3a 20 65 6e 74 72 79 20 66 6f 72 20 39 ac b7 |t: entry for 9..|
00000060 a5 a2 7f 20 6e 6f 74 20 66 6f 75 6e 64 20 69 6e |... not found in|
00000070 20 2f 65 74 63 2f 6d 74 61 62 0a 0a | /etc/mtab..|
------------------------------------------------------------------------

========================================================================
CVE-2021-3999: Off-by-one buffer overflow/underflow in glibc's getcwd()
========================================================================

While studying the vulnerability in realpath(), we also discovered a
vulnerability in the glibc's getcwd() function (which is used internally
by realpath() to resolve relative pathnames) -- an off-by-one buffer
overflow and underflow, but if and only if the "size" of "buf" is
exactly 1:

------------------------------------------------------------------------
48 __getcwd (char *buf, size_t size)
49 {
..
54 size_t alloc_size = size;
..
76 path = buf;
..
80 retval = INLINE_SYSCALL (getcwd, 2, path, alloc_size);
...
100 if (retval >= 0 || errno == ENAMETOOLONG)
101 {
...
110 result = __getcwd_generic (path, size);
------------------------------------------------------------------------
158 __getcwd_generic (char *buf, size_t size)
159 {
...
187 size_t allocated = size;
...
247 dir = buf;
248
249 dirp = dir + allocated;
250 *--dirp = '\0';
...
262 while (!(thisdev == rootdev && thisino == rootino))
263 {
...
441 }
...
449 if (dirp == &dir[allocated - 1])
450 *--dirp = '/';
...
457 used = dir + allocated - dirp;
458 memmove (dir, dirp, used);
------------------------------------------------------------------------

If, at line 48, the "size" of "buf" is exactly 1:

- and if, at line 80, the kernel's getcwd() syscall fails with the error
ENAMETOOLONG (because the current working directory is longer than
PATH_MAX),

- then, at line 110, a generic implementation of getcwd() is called;

- at line 250, a null byte is written to "dirp", which points exactly to
"buf" (because "size", and hence "allocated", are exactly 1);

- if the code block at lines 262-441 is skipped entirely (if the current
working directory corresponds to the "/" directory),

- then, at lines 449-450, a slash is written to "buf-1" (an off-by-one
buffer underflow, because at line 449 "dirp" was still pointing
exactly to "buf"),

- and, at lines 457-458, a null byte is written to "buf+1" (an
off-by-one buffer overflow, because at line 457 "used" is exactly 2).

It may seem impossible to satisfy the condition at line 100 (the current
working directory is longer than PATH_MAX) and the condition at line 262
(the current working directory corresponds to the "/" directory), but in
reality we can:

- in a child process:

- create an unprivileged mount namespace;

- create a directory longer than PATH_MAX;

- bind-mount "/" onto this directory;

- open() this directory and send its file descriptor to the parent
process (outside the unprivileged mount namespace);

- in the parent process:

- receive the file descriptor of this directory (which corresponds to
"/" and is longer than PATH_MAX) and fchdir() to it;

- execute a SUID program that calls getcwd() with a buffer of size 1,
which triggers the off-by-one buffer overflow and underflow.

Apparently, this vulnerability was introduced in February 1995 by the
very first commit in the glibc's git history (28f540f, "initial import")
and could be triggered without an unprivileged mount namespace, by
simply chdir()ing to the "/" directory:

------------------------------------------------------------------------
190 getcwd (buf, size)
...
218 path = buf;
...
226 pathp = path + size;
227 *--pathp = '\0';
...
242 while (!(thisdev == rootdev && thisino == rootino))
243 {
...
351 }
352
353 if (pathp == &path[size - 1])
354 *--pathp = '/';
...
359 memmove (path, pathp, path + size - pathp);
------------------------------------------------------------------------

Although "the size of buf is exactly 1" is a strong requirement,
vulnerable code like the following may exist in the wild:

------------------------------------------------------------------------
#include <unistd.h>
#include <stdio.h>

int main(int argc, char * argv[]) {
char buf[4096];
int len = snprintf(buf, sizeof(buf), "%s: cwd is ", argv[0]);
if (len <= 0 || (unsigned)len >= sizeof(buf)) return __LINE__;
if (!getcwd(buf + len, sizeof(buf) - len)) return __LINE__;
puts(buf);
return 0;
}
------------------------------------------------------------------------

bassmadrigal · 01-24-2022, 10:54 AM

Quote:

Originally Posted by Sl4ck3ver

A start/stop script for the "dhcp" package (rc.dhcpd), please :-)

There is a script included at the end of usb-and-pxe-installers/README_PXE.TXT.

This has been discussed here with no official answer as to why it is not included with the package.