ANALIA DE PEDRO SANTAMARIA wrote:
I'm going to try to explain myself better.
I believe that we understand what you seem to want to do, but that there are some
intrinsic problems with the way in which you are looking at this.
What I'm trying to do is create a permission system in Tomcat. This
permission system must allow or avoid the next connections:
- Receive from IP. The application with this permission only can accept
connections (or receive information) from an IP. It can't send anything or
connect to anywhere.
- Receive All. The application with this permission can accept connections
(or receive information) from any IP. It can't send anything or connect to
anywhere.
- Send and Receive IP. The application with this permission can accept
connection and connect to an IP.
- Send to IP. The application with this permission only can connect or
send information to an IP. It can't receive information or accept
connections from anywhere.
- Send to All. The application with this permission can connect or send
information to any IP. It can't receive information or accept connections
from anywhere.
"Accepting connections from" and "processing HTTP requests from" are two essentially
different things, and happen at different levels/moments in time.
"Connecting to" and "sending information to" is a third different and
independent thing.
Roughly :
- a TCP connection is "accepted" at the Tomcat/Connector level, long before anything
starts reading on that connection to receive the actuall HTTP request.
- then the HTTP request is read, and it is determined which application (if any) should
process that request
- and it is only after the above, that an application would (or would not)
process the request
In other words, if you really want to "block connections" (or allow them) from selected
IP's, then this is something that happens before the target application is even known, and
it cannot be specific per application.
On the other hand, when the connection has been accepted and the request has been read and
the target application has been selected, it is possible at the level of the selected
application, to check the source IP, and reject (or accept) the request.
(But at this stage, not the connection anymore, it's too late for that).
The second part concerns what the application can do, once it is running to
process a request.
Tomcat has basically no knowledge of any incoming or outgoing connection that the
application itself may be setting up with any "third party". Tomcat itself is not involved
in such connections, and it has no way to interfere with them.
That is the domain of the JVM which runs the application code, and it is at that level
that you can allow/disable such connections.
With the SocketPermission, I can avoid that one application connects to an
specific IP or any IP (not granting SocketPermission "connect"). But if I
try to avoid that one IP connects to the application (not granting
SocketPermission "accept"), it doesn't restrict all connections. For
example, I can connect to the application from a browser in another host.
(I'm using the Security Manager in a correct way because it works with
others permissions).
If I add <Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="localhost"/> to the context.xml, I can restrict the previous
example, but with this I restrict all connections, so it doesn't allow me
to do what I want.
If I combine the SocketPermission with the RemoteHostValve I can grant the
first three permissions (or connections) in my list above. But I need to
restrict the incoming connections (accept connections) to grant the last
two.
Yes, and it is all perfectly logical that it would be that way, because of where and when
things happen.
What I am trying to say, is that it is your requirements that do not fit the reality of
how things work. You are trying to combine, under one artificial "permission name",
things which are difficult to combine because they happen at different levels and have
different scopes.
For example, if you do not grant to an application the SocketPermission "accept", it means
that this application cannot open it's *own* listening socket and accept connections on
it. But this concerns listening sockets that your application would want to open on its
own, and it is totally distinct from (and has nothing to do with) the listening socket on
which Tomcat accepts HTTP requests (for this application and others).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
