There should be 9 that are used
can_network (Allow all network activity)
can_network_server (tcp and udp, requires a name_bind)
can_network_client (tcp and udp, requires a name_connect)
can_network_client_udp (udp requires)
can_network_client_tcp (tcp requires a name_connect)
can_network_server_udp (udp requires a name_bind)
can_network_server_tcp (tcp requires a name_bind)
can_network_tcp (tcp requires a name_connect and a name_bind)
can_network_udp (udp requires a name_bind)
The other port type parameter can be used to "lock down" udp connects
since name_connect does not work for udp.
So why don't we add name_connect and name_bind to the macros
where required.
I don't recall why, but name_connect was added the way it was
because
name_bind was done that way.
...
Also passing a lot of parameters in macros is somewhat frowned on,
since
it complicates the code quite
a bit. It was decided to break these functions in to multiple function
calls.
I don't argue with the breaking of calls - that seems like a good idea,
but if you say name_bind and name_connect are required in certain
scenarios, then we should probably add those to the networking macros.
For example, the port_type argument in base_can_macros could be used for
name_connect, not only for send_msg/rcv_msg. For name_bind I guess you'd
need another argument, since servers should be able to send/receive to
all ports (actually - should this be all unrestristed ports?)
>Basically I've been writing:
>
>can_network_client(domain)
>allow domain specific_port:tcp_socket/udp_socket name_connect;
>
>can_network_server(domain)
>allow domain specific_port:tcp_socket/udp_socket name_bind;
I'm thinking something like:
- include name_bind and name_connect where appropriate
- require socket_type (but only if udp/tcp not specified)
- include port_type in server for the port that server can bind to
(maybe require port_type too - why is all of this optional
if you want to enforce stricter policy?)
can_network_client(domain, socket_type, (, port_type)?);
can_network_client_(tcp|udp) (domain (,port_type)?);
socket_type - type of socket over which to communicate
port_type - server port the client is authorized to talk to
can_network_server(domain, socket_type, (, port_type)?);
can_network_server_(tcp_udp) (domain (,port_type)?);
socket_type - type of socket over which to communicate
port_type - server port the server is authorized to bind to/listen on
(it can connect to all unrestricted ports (but not name_connect?));
or something like that...
Then instead of calling can_resolve:
can_network_client_udp(domain, dns_port_t) or
can_network_client(domain, udp_socket, dns_port_t)
Instead of can_ldap:
can_network_client_tcp(domain, ldap_port_t) or
can_network_client(domain, tcp_socket, ldap_port_t)
--
Ivan Gyurdiev <ivg2(a)cornell.edu>
Cornell University