On Unix systems, binding to tcp port < 1024 from a process without root privileged is denied.
What was the initial reason and is it still valid ?
For example http server don't need root privileged to serve html page.
What process/protocol a Unix's user need to be sure that it runs with root privileged ?
Thanks
That port range is not supposed to be programmer defined.
It is reserved by IANA,
The Well Known Ports are those from 0 through 1023.
DCCP Well Known ports SHOULD NOT be used without IANA registration. The registration procedure is defined in [RFC4340], Section 19.9.
For differing opinions check,
From a linuxquestions thread (read at the link for more context)
The port 1024 limit actually bites itself in the tail. It forces a daemon practice that might open security holes which make the limit ineffective as a security measure.
Several of the core system services provide remote interfaces to client components through Remote Procedure Calls (RPC). They are mostly exposed through named pipe endpoints accessible through the Common Internet File System (CIFS) protocol, well known TCP/UDP ports and in certain cases ephemeral TCP/UDP ports. Historically, there have been many vulnerabilities in services that can be exploited by anonymous users. When exploited, these vulnerabilities afford the attacker the same privileges that the service had on the host.
These days, protocols like BitTorrent and Skype have moved over through ephemeral ports into the unreserved space and do not bother for root access. The target is not just bypassing this old reserved-port security; Today's protocols want to bypass even the network perimeter (Skype is a good example for that). Things will go further as network bandwidth and availability increase when every computer user will probably run a web server off themselves -- and maybe, unknowingly, be part of a botnet.
We need the security desired by these old methods
but it will need to be done with newer ways now.
Well, the original thinking as I recall from the days of BSD Unix was that ports < 1024 were expected to be reserved for "well known services", and the assumption was still that servers would be relatively rare, and that folks with root privileges would be presumed to be "trusted" in some way. So you had to be privileged to bind a socket to listen on a port that would represent a network service that other users would access.
Ports 1024-4999 were intended to be used as "ephemeral" ports that would represent the client's side of a TCP connection. Ports 5000+ were intended for non-root servers.
Obviously all of those assumptions went out the window pretty quickly. Check the IANA TCP port number reservation list to see just how high things have gotten.
One solution to this problem was the RPC portmapper idea. Instead of reserving a TCP port for each service, the service would start up on a random port and tell the portmapper daemon where it was listening. Clients would ask portmapper "where is service X" listening and proceed from there. I can't recall what security mechanisms were in place to protect well-known RPC services from impersonation.
I'm not sure there's a Good Reason these days for all of this, but like most of the *nix world things tend to accumulate vs. getting completely reinvented.
Anyone read Vernor Vinge? I remember him writing in one of his novels about a computer system in the far future that incorporated layers and layers of code from the ancient past, with the time still being represented by the number of seconds since some ancient date (1/1/1970 to be exact). He's probably not far off.
In the old days regular users used to login to Unix machines. So you wouldn't want an average user setting up a fake ftp service or something.
These days, the typical usage is that only the admin and a few other trusted people have logins to a server, so if the model was redone today, the < 1024 restriction might not be present.
This is a historical convention.
A long time ago, the number of systems was much smaller. There was also no DNS, FTP sites asked for your anonymous password to be your email address, and there was no spam.
It was essentially an implied "gentlemen's agreement". Systems were well administered, if someone messed this up, you knew who to talk to, or if they were petulant, getting kicked off the network pretty much meant staying offline.
Today, with TCP/IP on everything, this is provides no security anymore.
It makes sense for services which accept system-passwords to be running on privileged ports; this means that users with shell accounts cannot set up "fake" services on the same port to capture peoples' login details, or deny access by setting up nonfunctional services on the same ports.
If you had a multiuser box, and an unprivileged user was able to set up a rogue ssh daemon, they may be able to capture the passwords of other users and gain access to their accounts (of course they'd have to do it while the legitimate ssh daemon was down, perhaps for maintenance or during system startup or shutdown)
Things which don't accept system-passwords don't matter so much, although there are major security problems with sharing things such as web servers between users on a multiuser box (as shared-hosting providers have discovered)
