Gotta start as root to start as any other user, as only root can setuid etc
And since a lot of stuff is on lower ports, and there wasn't the complicated firewalls of today to dynamically flick around port routing depending on processes and the such, most programs grabbed the requested ports, and then setuid to the relevant daemon user, all by themselves (also forking, going into background, etc)
> Gotta start as root to start as any other user, as only root can setuid etc
TOPS-10, DEC's main operating system for PDP-10, had an interesting approach to this. The login system call, which was used to set the user ID for a user, was not privileged. However, it would return an error if it was executed when already logged in.
As was common with systems back then, there was a CLI that was built in to the OS and ran on all terminals without being logged in. It allowed you to run a restricted set of programs without logging in, including the login program.
One of those programs you could run without being logged in was queue, which was a program to view the print queue (and maybe other queues, like the queue of pending tape mounting requests?...I don't remember).
Unlike the login program, the queue program was also useful when logged in and so included many features and options beyond just what was needed by people who were not logged in. That included a flag to run other programs: queue/run:foo would run run foo.exe. (No, I don't remember why /run was ever actually useful).
Someone figured out that this allowed queue/run:ddt to run the DDT debugger, and that they could do this while not logged in thus ending up with a running DDT. They could then use the debugger to poke in a short assembly program to invoke the login system call and login as anyone they wanted, no password required.
I just started a new job (well, transferred to a new office of my old job), and discovered they are still running everything as root. Thankfully the main office doesn't do this, so the last 5 years of my life have been relatively pain-free, but I'm starting to dread the next 5...
And since a lot of stuff is on lower ports, and there wasn't the complicated firewalls of today to dynamically flick around port routing depending on processes and the such, most programs grabbed the requested ports, and then setuid to the relevant daemon user, all by themselves (also forking, going into background, etc)
Thankfully these days its all unneeded, yes