Requests for current-next (15.0-->15.1)

GazL · 03-13-2024, 03:32 AM

Not conflating overflowuid with "nobody" makes sense given the use of "nobody" to drop privilege: nothing should ever be owned by "nobody" while the purpose of overflowuid is expressly to own filesystem resources whose uids can't be represented in the filesystem.

I'd also be interested to see the reasoning for going back to sharing one uid value for both. It seems retrograde to me.

Petri Kaukasoina · 03-13-2024, 05:34 AM

What is nobody used for, anyway? The finger daemon used to run as nobody but it is history. nfs used it to map client root to server nobody. What else?

Programs seem to have their own nobodies now: vsftpd has ftpsecure, dovecot has dovenull, sshd has sshd.

rkelsen · 03-13-2024, 06:21 AM

^OpenVPN can use it.

GazL · 03-13-2024, 06:25 AM

Yes, the modern convention is to give each daemon its own unprivileged account to run under rather than sharing "nobody" as was done in the past. I've no idea what if anything is still using nobody today.

brianL · 03-13-2024, 07:12 AM

What happens if you log in as nobody? Somebody try it?

ctrlaltca · 03-13-2024, 07:52 AM

Quote:

Originally Posted by brianL

What happens if you log in as nobody? Somebody try it?

You can't, its shell is set to /bin/false:

Code:

nobody:x:99:99:nobody:/:/bin/false

Markus Wiesner · 03-13-2024, 09:58 AM

Quote:

Originally Posted by GazL

Yes, the modern convention is to give each daemon its own unprivileged account to run under rather than sharing "nobody" as was done in the past. I've no idea what if anything is still using nobody today.

The NetworkManager-openvpn package currently has a patch (source/xap/NetworkManager-openvpn/openvpn.nobody.nogroup.diff.gz) to use it instead of the default separate user:

Code:

--- ./shared/nm-service-defines.h.orig  2020-03-06 06:38:55.000000000 -0600
+++ ./shared/nm-service-defines.h   2020-05-03 20:12:26.997028745 -0500
@@ -126,8 +126,8 @@
 #define NM_OPENVPN_VERIFY_X509_NAME_TYPE_SUBJECT     "subject"
 
 /* User name and group to run nm-openvpn-service under */
-#define NM_OPENVPN_USER   "nm-openvpn"
-#define NM_OPENVPN_GROUP  "nm-openvpn"
+#define NM_OPENVPN_USER   "nobody"
+#define NM_OPENVPN_GROUP  "nogroup"
 #define NM_OPENVPN_CHROOT LOCALSTATEDIR "/lib/openvpn/chroot"
 
 #endif /* __NM_SERVICE_DEFINES_H__ */

I think it would be a good idea to drop the patch and create the nm-openvpn user/group. And while we're at it: both Gentoo and Arch have AFAICS an additional user "openvpn" for OpenVPN as a "normal" (non-NetworkManager) daemon. It would be great to get them both officially added.

Jeebizz · 03-13-2024, 11:27 AM

Quote:

Originally Posted by brianL

What happens if you log in as nobody? Somebody try it?

I'm just reminded of this now https://en.wikipedia.org/wiki/Outis

glennmcc · 03-13-2024, 01:15 PM

Upcoming change to ffmpeg.

Well, as a result of the bug report I filed,
--disable-pthreads will also disable vulkan thereby not requiring _both_ --disable-pthreads _and_ --disable-vulkan

https://trac.ffmpeg.org/ticket/10900#ticket

The new snapshot includes the change in the configure script.

https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2

vulkan_deps="threads"
vulkan_deps_any="libdl LoadLibrary"

Note:

ffmpeg still requires threads.
Therefore with --disable-pthreads, only ffplay & ffprobe get built but _not_ ffmpeg
(many, many items for ffmpeg have been changed to require pthreads)

J_W · 03-13-2024, 04:40 PM

Hi @glennmcc

I think we also have to consider that the latest git master source of FFmpeg includes API changes.

commit:783d00b on Mar 7, 2024 (ibs: bump major version for all libraries)

lonestar_italy · 03-13-2024, 05:44 PM

Code:

Wed Mar 13 19:46:48 UTC 2024
a/etc-15.1-x86_64-9.txz: Rebuilt.
       Added proftpd user (97) and proftpd group (97).
       Added nm-openvpn user (320) and nm-openvpn group (320).
       Added openvpn user (443) and openvpn group (443).
       Added overflowuid user (65534) and overflowgid group (65534).

Maybe some sort of check/warning would be good to find out if uids/gids are already used in the system for something else?
Few of these new ones being assigned, I've been using them for other things for many years.

volkerdi · 03-13-2024, 07:02 PM

Quote:

Originally Posted by lonestar_italy

Code:

Wed Mar 13 19:46:48 UTC 2024
a/etc-15.1-x86_64-9.txz: Rebuilt.
       Added proftpd user (97) and proftpd group (97).
       Added nm-openvpn user (320) and nm-openvpn group (320).
       Added openvpn user (443) and openvpn group (443).
       Added overflowuid user (65534) and overflowgid group (65534).

Maybe some sort of check/warning would be good to find out if uids/gids are already used in the system for something else?
Few of these new ones being assigned, I've been using them for other things for many years.

If that ends up being the case I'm not sure what we could do about it, since I'm going to be doing a static assignment here. I do check the SBo list and use the established UID/GID from that where possible. OpenVPN I used the TCP port number.

Anyway, I'll probably never assign anything from 500-999, so that's all open for local system usage.

biker_rat · 03-13-2024, 09:58 PM

https://archive.mesa3d.org/mesa-24.0.3.tar.xz is available.

chrisretusn · 03-13-2024, 11:52 PM

Quote:

Originally Posted by lonestar_italy

Code:

Wed Mar 13 19:46:48 UTC 2024
a/etc-15.1-x86_64-9.txz: Rebuilt.
       Added proftpd user (97) and proftpd group (97).
       Added nm-openvpn user (320) and nm-openvpn group (320).
       Added openvpn user (443) and openvpn group (443).
       Added overflowuid user (65534) and overflowgid group (65534).

Maybe some sort of check/warning would be good to find out if uids/gids are already used in the system for something else?
Few of these new ones being assigned, I've been using them for other things for many years.

I use https://slackbuilds.org/uid_gid.txt as my guide. Only one in this listing is 320, the rest are not used. Probably time to update this list.

Code:

nm-openvpn
=======
User:   nm-openvpn	UID: 320        GID: 320
Group:  nm-openvpn			GID: 320

jloco · 03-14-2024, 01:07 AM

The "major mess" mm (that's actually "maintainer-mode" for those whom don't know) problem and solution.

For some time the *mm components have been getting stale-- this isn't a problem as most of them are current libraries used by the system. But eventually more apps will require the newer ABI versions and Slackware can't accomodate them. As noted then, there was breakage when updating them, which is why I suggest not updating them, but extending them.

I propose adding a few new mm packages into the mix, namely "cairomm1" with the newer 1.16 ABI. A "glibmm2" with the 2.68 ABI. A "gtkmm4" for the GTK4 ABI, and last but not least a "pangomm2" with the 2.48 ABI. (package names are negotiable

I was specifically looking into the glibmm package as I wanted to build something dependent on a newer release, yet noticed things broke if I upgraded it in place, so naturally, making a new package seemed the most logical next step. In this process, I noticed each one of this puzzle was needed for another piece to fit together. Now with all 4, I can build newer applications while not breaking the old ones already included based upon glibmm libraries (cdrdao, pavucontrol, and gparted came up in my search). I assume this will also help along other newer software to become buildable as well.

All of these are needed for newer GNOME software, and I presume other things out and about on the net as well. My hastily edited scripts are here along with the slackbuilds I was checking for breakage along the way. Everything builds cleanly just like it had without these new packages being added as well. I know the GFS project uses something like these to build software as well, so it'd benefit the community to have them directly included in Slackware, where they belong.