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