It was thus said that the Great Amalan, S once stated: > > Thanks much. This explains why my installation did not need root > privileges - I was running it on port 1150 or so. > > This also brings up the question: is there a reason to set the port to > be below 1024 so that only root can start it up? Is there a downside to > running Apache on a port greater than 1024? The default port defined for HTTP (the protocol Apache supports) is 80. If the webserver is running on another port, you have to include the port as part of the url: http://www.example.net:81/ > There must have been some reason for designing it in such a way that the > process owner gets dropped from root to a non-zero UID account. I guess > I am confused because if you need to be root to start it up, why should > the process owner be dropped after binding to the privileged port to a > non-zero UID account? And if you weren't root to begin with you wouldn't > be able to startup Apache anyway. TCP/IP was primarily designed in the late 70s/early 80s on timesharing systems, with most (at the time) predefined ports being assigned at number 1024 or less. To insure some security (at least under Unix; possibly the same under other timesharing systems) the port range 0-1024 was marked as special and only priviledged accounts could bind to those ports (on Unix, this is the root account). We're still stuck with that today (at least, under Unix and Unix-like systems), and until such time as ownership of TCP or UDP ports can be assigned, programs will still have to start as root to bind to those ports. The reason to drop privileges after binding to the port is that under Unix (and Unix-like) systems, root can do *anything*---all security and ownership checks are bypassed when the UID is 0 [1]. -spc [1] This is slowly changing, now that SELinux is gaining popularity. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|