Access controls on topics and services?

asked 2016-02-01 11:37:57 -0500

lucasw gravatar image

updated 2020-11-21 12:05:58 -0500

Has anyone considered this or tried to implement this?

It would be great to have a system where certain topics are only visible/usable by nodes with the right permissions. Maybe the permissions would stem from unix users, or a network authentication scheme.

Maybe a solution would be to launch multiple roscores, have the protected one be launched by the system on boot, and then it would listen through a bridge to the 'user space' topics, and internally it could have any number of admin/root topics that the user would not see. The user would have to launch a special client node for their side of the bridge. The protected master would have to be on a private network.

edit retag flag offensive close merge delete



Sounds to me partitioning your node graph would work as well. IIRC something like rocon_multimaster or multimaster_fkie with the proper settings would result in nodes seeing only subsets of topics.

gvdhoorn gravatar image gvdhoorn  ( 2016-02-01 15:01:40 -0500 )edit

This could be done on the networking level, using iptables to control access to the TCP/UDP ports opened by the nodes. Probably, there are also some nice firewall GUIs that can create such rules. The "owner" extension allows for rules based on Unix users, as you mention.

Nicolas gravatar image Nicolas  ( 2016-02-02 06:53:57 -0500 )edit

The firewall idea is interesting, but wouldn't it disrupt the normal ROS way of discovering services and topics? All nodes would still see all topics and services, they would just not be able to connect to the nodes advertising them.

gvdhoorn gravatar image gvdhoorn  ( 2016-02-02 07:11:52 -0500 )edit

I agree, it would be better if at least the rosmaster knows about access rights and provides this information. But I do not think this could be done with the current structure. Apart from that, for solid access control, you will probably end up with iptables on the low level.

Nicolas gravatar image Nicolas  ( 2016-02-02 07:51:18 -0500 )edit

Anyway, it could make sense to view all available resources. When an actual connection attempt between nodes is refused (with REJECT, not DROP), you should already get a more or less useful error message.

Nicolas gravatar image Nicolas  ( 2016-02-02 07:57:01 -0500 )edit