非ROOT用户启用80端口的变通办法

在linux中，为了安全起见，小于1024的端口都归root用户所有，其他用户没有使用这些端口的权限。

如果使用root用户启动tomcat又不太规范和安全，所以可使用如下命令完成端口的启用，然后在于tomcat用户启动tomcat。

使用root用户执行：
iptables -t nat -A PREROUTING -p tcp ——dport 80 -j REDIRECT ——to-port 8080

 

将80端口映射到8080上了.

 

-----------------------下面为参考内容---------------------------------

 

 

1.使用非root用户，修改tomcat启动端口为80，启动时报错

2008-9-11 14:16:24 org.apache.tomcat.util.digester.SetPropertiesRule begin
警告: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'debug' to '0' did not find a matching property.
2008-9-11 14:16:24 org.apache.catalina.core.AprLifecycleListener init
信息: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/jdk1.5.0_16/jre/lib/i386/client:/usr/jdk1.5.0_16/jre/lib/i386:/usr/jdk1.5.0_16/jre/../lib/i386
2008-9-11 14:16:24 org.apache.coyote.http11.Http11Protocol init
严重: Error initializing endpoint
java.net.BindException: Permission denied:80
        at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:502)
        at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
        at org.apache.catalina.connector.Connector.initialize(Connector.java:1058)
        at org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
        at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
        at org.apache.catalina.startup.Catalina.load(Catalina.java:530)
        at org.apache.catalina.startup.Catalina.load(Catalina.java:550)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
2008-9-11 14:16:24 org.apache.catalina.startup.Catalina load

2.这是一位朋友的解释

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.                        

        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".