Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 28 Jul 2005 12:29:58 +0200

Andrew Johnson wrote:

Shouldn't a propertySurveyor also be given access rights information

(i.e. whether a particular property is writable or not)? Do you

intend to use a different mechanism to communicate that somehow?

Unfortunately your very clever template mechanism only works with

fully symmetrical property sets; in many cases I think we're going to

have to write all three traverse() routines ourselves, to cope with

read-only properties.

This is a really interesting issue - here's what I've been thinking:

To avoid loads of exception being thrown, the traverse methods should

only reveal properties that are appropriate for the traverse's use. The

viewer traverse should only reveal properties that are readable, the

manipulator traverse should only reveal things that are writable, the

surveyor traverse should reveal everything that's available including

the information if something is writeable.

This works so far, as DA only distinguishes between read-only and

read-write properties.

So - what are we doing with access rights that are based on AccessSecurity?

For V3, AccessSecurity stuff is spread through different layers:

- For the client, AccessSecurity change callbacks and the related stuff

are an integral part of ChannelAccess and its network protocol; access

rights info is closely coupled to the data

- The CA server does the client authentification (checks user and host name)

- A separate module (i.e., library) holds the AccessSecurity

configuration and does the on-line rule-based checks (including CALC

based rules that have other CA client connections)

- The database definition (dbd file) holds the AccessSecurity level info

per field (as part of the record definition)

- The database (db) holds the AccessSecurity group info per record

instance (as ASG field of record instance)

If we try to copy the functionality to V4 with the least changes in

structure and mechanisms, the service (EPICS database) will still have

to hold and provide AS level and group info to the server(s). These

would probably be implemented as properties in the record's views: Group

info as a top level property (or somewhere on record level), AS level

info as a subordinate property - for every property. (Is there a way to

make this easier?)

The server (in this case CA) will have to use that information and will

probably continue to use the checks of the AS library.

How will the AS info be connected to the property catalogs?

I see problems with Jeff's initial suggestion ("When implementing a

property catalog for an EPICS PV there may also need to be subordinate

properties for the access rights so that they might be dynamic."): A

property without read-access will disappear from the viewer-traverse -

and with it a subordinate property will simply go away. The client

subscribing to this sub-property will probably get a connection loss

exception thrown.

My favourite solution at the moment: (btw. I have been mentioning this

problem and my suggestion in several emails without reaction)

The access rights property is completely taken out of the data and the

CA server reveals it as part of the surveyor traverse. That way it is

assured that it always exists (even if read-access to the data is taken

away) and clients get updates for a subscription as they expect.

Ralph

Other question: Will we keep the same mechanisms for Access Security in

V4? Are there other techniques that should be implemented or at least

made feasible by defining appropriate AS plug-in APIs? What about the

user/password credentials (probably checked against an auth server) that

we saw at the ABB show? I liked that, admittedly. Is the AS group and

level info in the EPICS database generic enough to support other

security mechanisms?

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System