I installed tomcat4.0.2 in /home/user. Everything works. But after I edited server.xml file to changed port from 8080 to 80 I can not start tomcat anymore. I get this error in Catalina.out file: Why? Thanks. Catalina.start: LifecycleException: null.open: java.net.BindException: Permission denied:80 LifecycleException: null.open: java.net.BindException: Permission denied:80 at org.apache.catalina.connector.http.HttpConnector.initialize(HttpConnector.java:1130) at org.apache.catalina.core.StandardService.initialize(StandardService.java:454) at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:553) at org.apache.catalina.startup.Catalina.start(Catalina.java:780) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) ----- Root Cause ----- java.net.BindException: Permission denied:80 at org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.java:950)
httpd is not already running on 80 is it? Did it get autostarted at boot? Bruce - did you reinstall to get going again? Guy [ April 22, 2002: Message edited by: Guy Allard ]
Thanks Guy and Tim: I restored everything (tomcat, jdk, and servlets that access data on an as/400). This time I installed jdk and tomcat in /home/user so that I don’t have to grant authority when I work in tomcat etc. I have to get a boot disk now. Tim is right, when I use root, tomcat started OK. Bruce
in server.xml file you will see this tag: <Connector className="org.apache.catalina.connector.http.HttpConnector"<br /> port="8080" minProcessors="5" maxProcessors="75"<br /> enableLookups="true" redirectPort="8443"<br /> acceptCount="10" debug="0" connectionTimeout="60000"/> You can change port="8080" to port="80". That's it! Bruce
Sorry it looks like I misunderstatood Gabriel's question. How to start Tomcat at port 80 using regular user login? I did not know. I guess one has to change the java policy file.
It's not a Java issue which could be addressed in a policy file. It's a fundamental Linux/Unix design choice. All ports below 1024 can only be bound by a process with "root" permissions. The reasoning is that if you are connecting to a port below 1024 you can be pretty sure that you are using a service setup by the system administrator of the system, and not some "trojan" set up by a malicious or naive user. If you really need Tomcat to listen to port 80 then you have two choices: (1) Run Tomcat as "root", or (2) run some other software as "root" which hands off HTTP requests to a Tomcat running as a regular user. The first option is dangerous and not recommended for real use :- it could allow web application code to inadvertently corrupt system files, for example. The second option is usually achieved by running a web server such as Apache or Roxen on port 80, and configuring it to hand off all or some web requests to a Tomcat server. This is such a popular option that there are full setup details on the Tomcat web site.
Thanks Frank for the explanation. Are you suggesting set Tomcat port at above 1024 (8080 for example) and set apache at port 80? I have not used Apache with Tomcat. I will take a look at this. Why Run Tomcat as "root" is dangerous? How could it allow web application code to inadvertently corrupt system files? Can you give a simple example or direct me to a resource that explains this? Thanks! Bruce
Why Run Tomcat as "root" is dangerous? How could it allow web application code to inadvertently corrupt system files? Unix/Linux systems are always set up with differing levels of user permissions. Every file has separate read, write and execute permissions for three categories of users: the user who "owns" the file, users in the same "group" as the owner, and everyone else. This fine-grained access control allows system configurations to be readable but not writeable by regular users, for example, and allows individual users to mark private information as unreadable by other users. The "root" user can completely bypass this protection. "root" is the super-user, able to read, write and/or execute any file on the system. "root" access should be the most closely guarded secret on any system, If a process is owned by "root" it can do anything on the system. Now imagine that I have a Tomcat server running as "root", and deploy a web-application which allows the input of a filename and displays the contents of the named file. Simply by putting the full path to a private file in the input box, any user anywhere can then read secret files. And if the server is on the general internet, you might even find Google has indexed those secret files and made them searchable! You might think you are safe from this sort of thing, but if your program ever builds a local filename to read from (or worse, to write to) based on some sort of external input there is little to stop somone entering a relative path instead of just a filename, and having access to the whole system with super-user priveleges. The bottom line: Unless you are both a Linux/Unix system admin and Tomcat configuration guru, don't even think about running something like that as "root".
Thanks Frank for the explanation. It is very interesting. I don’t completely understand what you said. I will have to figure out a way to defeat my own Linux/Tomcat then I will understand this. Windows does not have such thing as “root”, is Tomcat on windows always vulnerable to hackers? (I mean more vulnerable than Tomcat on Linux) Thanks [ June 18, 2002: Message edited by: Bruce Jin ]
The nearest that Windows has to "root" is "Administrator" priveleges (NT, 2000 and later), although the Windows security model is nothing like as flexible and configurable as Linux/Unix. That's all down to the history of the systems. Windows systems have always been essentially single-user machines - you log on then you have control of the whole system. Unix and Linux systems have always been esssentially multi-user - it is assumed that more than one user is logged on, and a variety of services will be running as various different users. The problem with putting something like a web server on a Windows machine is that then lots of different people can be accessing the machine at once, and suddenly you have a multi-user system! If you look in Windows documentation, you will find that it strongly recommends that you don't run services like this as an Administrator user either.
With all due contempt for Microsoft, IMHO, the idea that there exists a single account that has the ability to rape anything in the system doesn't strike me as a necessarily being superior security model. I can set up some pretty nasty restrictions on an NT administrative account. Of course, someone will probably come along and broadside security anyway, but that's because I'm running Windows, not because the security model itself is technically inferior. The standard way to get around this problem is to have the app come up as root, get the restricted-access resources then suid itself down to a less privileged level. Apache lets you set the "working" user and group in the httpd.conf file, for example.
I agree. The trouble is that (AFAIK) a Java program running in a JVM just doesn't have that option. If you start the JVM as root (in order to bind to port 80), it carries on running as root. Which is why I recommended option (2) above.
Hi, I just run into the same problem, in case anybody still checks this thread I'd just like to appear that there are ways around this problem. I've found http://www.olafdietsche.de/linux/accessfs/ which allows you to give other users than root access to ports below 80. I haven't tried that, though, as I will be going for the other suggestion I've found: use a firewall (like iptables) to redirect requests to port 80 to another port, on which Tomcat will be running as non-root.