how on earth does openssh not only have incredibly fucked versioning but is the only package i've ever seen to mention a "privilege separation" chroot path which actively breaks non-root builds. are you fucking kidding me bruh. "privilege separation chroot" defaulting to /var/empty and it immediately errors if it can't create it????? why are your version strings like that bruh?????
115
Replies
·
0
Boosts
i looked up the pthreads API and screamed as if burned
i am learning so many interfaces that people who assuredly were considered experts and innovators in computing agreed to implement and it truly astounds me
i like the first linux threading impl https://www.man7.org/linux/man-pages/man7/pthreads.7.html#:~:text=LinuxThreads
LinuxThreads
The notable features of this implementation are the following:
In addition to the main (initial) thread, and the threads that the program creates using
pthread_create(3), the implementation creates a "manager" thread. This thread handles thread creation and termination. (Problems can result if this thread is inadvertently killed.)Signals are used internally by the implementation. On Linux 2.2 and later, the first three real-time signals are used (see also
signal(7)). On older Linux kernels,SIGUSR1andSIGUSR2are used. Applications must avoid the use of whichever set of signals is employed by the implementation.Threads do not share process IDs. (In effect, LinuxThreads threads are implemented as processes which share more information than usual, but which do not share a common process ID.) LinuxThreads threads (including the manager thread) are visible as separate processes using ps(1).
so the page tries REALLY hard to cast LinuxThreads POSIX nonconformance as problematic and i think every single one is Good Actually
particularly these two are evidence of desperation:
When a thread calls
execve(2), all other threads are terminated (as required by POSIX.1). However, the resulting process has the same PID as the thread that calledexecve(2): it should have the same PID as the main thread.
this is the first time it mentions "PID", but since these threads are just "processes with more sharing", they also have distinct PIDs--it is deeply misleading to (as in the first bullet) say only that getpid(2) returns a different value, since the PID is, once again, a kernel-level globally addressable value, much like the page cache.
no one on the fucking planet would ever claim that threads-as-processes should have been implemented by having the kernel mutate the fucking PID of a running process.
and exec() shouldn't be allowed if there are any threads instead of introducing riddle semantics
exec() is just an incredibly fucked API in the first place. "yes, i want to keep my PID the same, but start executing different code. no, i don't need to conserve any memory across the call, i have no need for partial evaluation"
trying to decide if exec triggering the suid bit is in any way clever, given the knowledge that exec was the only API to execute code for an incredibly long time
i completely cannot get over the idea that you can require exec() to specify a readable+executable filesystem path, but not have a posix_spawn(). there's absolutely no fucking way that's easier in any way. immediately when MMUs became ubiquitous this should have been deprecated
also mmmmyeah we're gonna allocate three separate bits for the executable flag like it's a permission even though any readable file can be copied and made executable and we're gonna make that the final of the three permission flags and that's how we're gonna close out the "mode" field
literally just fucking sandwich ACTUAL FUCKING PERMISSIONS which are replicated THREE TIMES! yes we do ABSOLUTELY make sure to separate the two that actually matter by acting it makes sense for a user to belong to multiple groups but a file is only ever pertinent to one group ever
i also take issue with specifying each separate permission for each group and not transposing the bit matrix (if you're going to use a bit matrix). that is blatantly just fishing for off by one errors or just fucking PEBCAK since, again, it makes no fucking sense that a file only ever has one group
god fuck and this is fucking why you MUST have a "default" group per user because the file gid is set by the process gid, because a process is also something that is always associated with a group, but only one
which is what makes group perms so FUCKING ANNOYING to even try to use because they're not sticky by subdirectory. ext4 has a mount flag for this. btrfs does not
the only remotely interesting thing btrfs does is hash bucketing directory entries by crc value of the path name for stable iteration which is absolutely half-assed and not terribly useful except for btrfs implementers but hash bucketing is a deeply underrated trick
if the buckets are 1 bit in size and each maps to 1 bit of the input and your hash function is the identity function you get a trie
and tries are literally the best data structure ever
