Group locking of a device server

Dear all,

As far as I know, the basic locking mechanism in Tango only supports locking a given device server by only one other device server (or a client), which means that from now on, only the locker can access the locked device's methods.

This is fine for most cases, however, in some cases it should be better if a group of devices, and only these devices could access the methods of a given Tango device server (thats what I call "group-locking").

I dont see a built-in way to handle this problem, but maybe I am missing something.

The basic workaround, what I am using at the moment, is that I add a +string parameter to the end of every method of the class which I would like to be group-locked, and this string is the password. When a device is group-locked (a method, "DevString GroupLock()" is called), a random string is generated and this string will be the new password, and only the caller will know it. Then, I can distribute this string to a group of Tango devices, which can use the string password to access the group-locked device. Although the target device is not locked in the Tango-way (every method is publicly callable), if the password parameter is not correct, the methods return without doing anything (with an error code). Every device with the password can group-unlock the device at any given point using the password ("void GroupUnlock(DevString passwd)"). If the device is unlocked, the password string is not checked and every method can be called by everyone.

Is this approach correct, or is there a better way to do this?

Sidenote: is it possible to determine the name of the caller in a Tango device when one of its method is called? In the documentation of the built-in Lock() method, the device name of the caller is stored, so a device always knows who the locker is. But how exactly it knows this? If a method does not have the caller as a parameter, how can I determine who called this method? If this is possible, it would make the group-locking easier (without using passwords, I could simply store the list of devices who can access the locked device freely and unlock it).

Thanks in advance,

Arpad
Hi Arpad,

you are right that Tango does not offer a locking mechanism for a group of clients. In our case we assume all clients which have write access to devices in a control system can be trusted. You could also use the security filtering mechanism in Tango to restrict which clients (identified by their host ip + uuid) have write access to the commands you want to protect.

Your suggestions sounds like it would solve the problem too even if the idea of sending a password attached to each command looks a bit like a hack. It will solve your problem. There is a class in Tango (in blackbox.h) which returns the client's identity but from it identifies a client by its pid and host ip. I don't know if that is enough for you. Maybe you could request access to the device server from the clients dynamically using a password or other mechanism and then keep a list of the client id's which are authorised. This would avoid you sending a password each time.

Two other possibilities you might want to consider are:

(1) use the Tango filtering mechanism to restrict which clients can have write access to your device - this could even be a separate Tango database

(2) use the REST api to access your device and use tomcat's security mechanisms to control access to your device. Note the REST api also relies on the Tango security. This however might be too heavy as solution which slows down your device access.

Up to you to decide which solution fits your needs best.

Andy
Dear Andy,

Thank you for your very detailed answer.

This BlackBox class is very promising, but the documentation is very limited, to say the least. I have looked into it, but strangely, it seems to be always empty for my devices. The blackbox_depth variable reads 0 all the time despite accesssing the device with multiple commands/attribute read/writes, and any attempt to read into the blackbox with "blackbox_ptr->read(someindex)" throws an exception.
Arpad
Dear Andy,

Thank you for your very detailed answer.

This BlackBox class is very promising, but the documentation is very limited, to say the least. I have looked into it, but strangely, it seems to be always empty for my devices. The blackbox_depth variable reads 0 all the time despite accesssing the device with multiple commands/attribute read/writes, and any attempt to read into the blackbox with "blackbox_ptr->read(someindex)" throws an exception.

< I have accidentaly submitted the post mid-writing>

So, am I missing something, this blackbox should be turned on first? I have not found any command related to this black box, it seems to be automatic.

Thank you,

Arpad
Hi Arpad,

Take care in using this BlackBox class. It is not documented because it is not intended to be used by user. Today, it's a kernel
class and its interface may change between Tango releases.
The rule of this class is to provide data for the "BlackBox" feature that every Tango device has. For instance, in Jive, select a
device then right click and choose "Test device", go to the "Admin" tab and click on the Execute button closed to the Blackbox
label. You may increase the depth up to 50.

Regards

Emmanuel
Manu
Hi Arpad,

Take care in using this BlackBox class. It is not documented because it is not intended to be used by user. Today, it's a kernel
class and its interface may change between Tango releases.
The rule of this class is to provide data for the "BlackBox" feature that every Tango device has. For instance, in Jive, select a
device then right click and choose "Test device", go to the "Admin" tab and click on the Execute button closed to the Blackbox
label. You may increase the depth up to 50.

Regards

Emmanuel


Thank you for your advice.

I think I will return to the password-protecting solution then, it seemed to work. Although, I completely agree that it feels like hacking, thats why I posted here to check if there is a better solution to this problem. For example, I can add a +string parameter to every command (usually done by changing the parameter type to DevVarLongStringArray or DevVarDoubleStringArray, which is a bit clumsy), but I can not do this for attribute write operations, they cannot be protected by passwords, as I see it. I must use get/set methods instead of attributes, or Readonly attributes and password-protected Set methods for writing them.

Luckily, only some of my devices needs to be able to allow group-locking.

Again, thanks for the help,

Arpad
 
Register or login to create to post a reply.