> 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@xxxxxxxxxxx>
Cornell University
|
