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?????
ok so they decided to reinvent sudo for sshd root https://github.com/openssh/openssh-portable/blob/master/README.privsep if i cannot disable the sshd build (reading ./configure --help in a crazed demented rage did not see the flag for it) i'm going to commit several murders
how do you spend 8kb of text and provide multiple detailed ASCII art diagrams regarding your privilege separation methodology and oh my god wait does it really require sshd to be root too yes it literally does are you fucking kidding me
this is so fucked
sshd is the main entry-point binary for the server. This binary retains privilege but performs a very limited set of tasks: loading and checking the configuration, listening for incoming connections
and monitoring the status of connections through the pre-authentication phase of their lifecycle to implement the MaxStartups and PerSourcePenalties features.
NONE OF THESE THINGS REQUIRE ROOT WHAT THE FUCK
@hipsterelectron Maybe I'm VASTLY missing the point here, but doesn't listening on port 22 require root, because 22 is a privileged port? Isn't there a tradition of servers being forced to use root on linux for this reason even if they don't need it for other reasons?
how is anyone ok with this????? it takes half the document and two fork/execs before it gets to why sshd-auth would need root:
All operations that require privilege, such as looking up user information, private key signatures, checking passwords, etc are performed by RPC to the parent sshd-session process.
- looking up user information????????
- i think you can calculate cryptographic signatures without root????
- the fuck do you mean """"checking passwords"""""
i have been informed that even looking up the list of users requires root and have concluded that the unix user model is well-designed to suit the bell labs HR system from the 1970s and was never a serious general permissions model
@hipsterelectron under Linux at least, getting a list of users on the system does not in fact require root
@freya i was told /etc/shadow requires root and that it performs password auth by checking that which seemed roundabout and when i remembered su exists i decided this was a remarkably strange decision indeed. i have decided the other reasons are also wrong but after a friend was confusingly hostile to me i have decided not to share further thoughts about this system to fedi.
meanwhile i will probably have to patch the codebase in a complex way that will produce constant merge conflicts if i want to achieve the thing i was trying to do in the first place, which was to build the ssh client and not the server.
i wouldn't have noticed anything in the first place if this wasn't the first package i've ever seen that produced a permissions error from the spack sandbox. i don't understand how
@hipsterelectron /etc/shadow requires root but /etc/passwd does not
@hipsterelectron changing user to the target user after login requires root