One reason why people sometimes execute network services as superuser (i.e.,
root) is the fact that Linux, like most operating systems, doesn't allow non-privileged users to bind sockets to the so-called System Ports (a.k.a. Well Known Ports or privileged ports).
One can't say that this is generally bad practice, as many network services make use of privilege separation to mitigate potential security vulnerabilities. (Usually, privilege separation is done by making use of
setgid(2), or related system calls, which are standardized in POSIX.1-2001.)
If no privilege separation technique is applied, running network services as superuser is bad practice.
Unfortunately, people are often confronted with the problem that they would like to allow an application to bind sockets to System Ports, but the respective application doesn't do privilege separation.
Fortunately, Linux provides a privilege separation mechanism known as
capabilities(7) that works on the operating system level. Here are the probably most relevant parts from the man page:
Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.
Since kernel 2.6.24, the kernel supports associating capability sets with an executable file using
setcap(8). The file capability sets are stored in an extended attribute (see
As you can find out from the capabilities list in the man page, the capability to to bind sockets to system ports is
setcap(8), it can be assigned to an executable file
some-executable like this, for instance:
sudo setcap cap_net_bind_service=+ep /full/path/to/some-executable