This is more idle curiosity than anything else. A friend of mine asked me 'which port range is it that only root can use under Linux?' I told him 0-1024 were restricted. Then he asked my why it was so and... I was at a loss. No idea whatsoever.

Is there a reason why these ports are restricted and 1025-65535 are not?

Most major network services (HTTP, FTP, SSH, Telnet, HTTPS, POP, SMTP, etc) are in this range so possible answers I thought of:

  • An untrusted user could run a program that listened on these ports for logon details.
  • An untrusted user could run an unauthorized server application.

Can anyone shed light here?


Suppose you're exchanging data with a computer on a port <1024, and you know that computer is running some variant of unix. Then you know that the service running on that port is approved by the system administrator: it's running as root, or at least had to be started as root.

On the wide, wild world of the Internet, this doesn't matter. Most servers are administered by the same people as the services running on them; you wouldn't trust the roots more than the other users.

With multiuser machines, especially on a local network, this can matter. For example, in the days before civilian cryptography, a popular method of running shell commands on another machine was rsh (remote shell); you could use password authentication, or you could authenticate just by proving you were user X on machine A (with machine B knowing that X@A could log in as X@B with no password). How to prove that? The rsh client is setuid root, and uses a port number <1024, so the server knows that the client it's talking to is trustworthy and won't lie as to which user on A is invoking it. Similarly NFS was designed to be transparent with respect to users and permissions, so a common configuration was that on a local network every machine used the same user database, and user N at A mounting filesystems from server B would get the permissions of user N at B. Again, the fact that the NFS client is coming from a port number <1024 proves that root at A has vetted the NFS client, which is supposed to make sure that if it transmits a request purporting to be from user N then that request really is from user N.

Unauthorized users not being able to run servers on low ports is another benefit, but not the main one. Back in the days, spoofing was quite the novelty and users running spoof servers would be quickly quashed by vigilant administrators anyway.

  • 2
    So, sort of a poor-man's authentication, then? Does this convention have any real benefit in modern *nix-like operating systems? – Andrew Lambert Jul 13 '11 at 1:10
  • 2
    @Amazed: The unix world is conservative, so the question to ask is "Does it cause any real trouble?" (and it should be answered in the full knowledge that every sever worth running has a command line argument to change the port). – dmckee Jul 13 '11 at 2:47
  • 5
    @dmckee it could also be argued that such a design leads to more servers running as root, even if they have the option of running on alternate ports. – Andrew Lambert Jul 13 '11 at 4:10
  • 4
    @Amazed It can still occasionally be useful today, on local networks. I don't think it leads to more servers running as root, services can bind the port then drop privileges, or use capabilities if available, or the admin can redirect a port on the firewall configuration. I don't think it would be put in if unix was designed today, but it doesn't hurt. – Gilles Jul 13 '11 at 7:11
  • 1
    This nonsense should long be gone from the kernel. No port number should have any special meaning. The "reasoning" behind that design is long outdated (I'd think it was controversial even at design time). But what's worse then the idea of any special number ranges that are "trustworthy" are the implications. Webservers need to be executed as root just to serve webpages. A single exploit and the hole server is gone. And what for? For legacy design that never even slightly worked. – masi Sep 15 '18 at 0:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.