Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 28 Jul 2005 14:32:34 -0600

interesting questions - every one of them

> 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.

We probably all agree that a read only property should not be seen in a
modifiable property catalog, but should be seen in the viewing and surveying
property catalog. Likewise, a no-read property might be seen in the surveyor
interface, but not in the view or modify catalogs. 

But perhaps this has no impact on connectivity, or lack of connectivity
might be an independent access security right - in addition to the current
read and write limitations. Currently, the CA server allows clients to
connect independent of what the access security system says. It is only the
read/write type of operation that is currently limited by access security.
Assuming that we wanted to support it, loss of connectivity might be
draconian in that you would not be able to subscribe for resumption of
connectivity with the server, but perhaps that is the job of a name service.

Nevertheless, even if we did not loose connectivity I see now that we might
get an exception from the access security subscription update because we
don't have read access to the parent property of the access rights - because
the find terminates looking for the parent property.

> 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.

My current perception is that it would be preferable to not add additional
CA programming interfaces for monitoring the current state of the access
rights, as in the past. 

I interpret your message to indicate that a client might have a special
subscribe interface where he can request to be handed with each state change
update a surveyor interface. I hadn't thought of that as I was thinking that
an update implies a read only data instance and hence a viewing type of
interface. This might be a good idea because it might be the only way to
monitor for changes in the structure of the data. This is definitely a good
issue to consider at this point.

> What about the user/password credentials (probably checked against 
> an auth server) that we saw at the ABB show?

My current inclination is that the server should call a generic interface to
interact with a PK authentication service as you suggest.

Sorry, if you mentioned these issues before and I didn't get the message.
There is a vast amount of mail and sometimes it's hard to keep up.

Jeff

> -----Original Message-----
> From: Ralph Lange [mailto:[email protected]]
> Sent: Thursday, July 28, 2005 4:30 AM
> To: [email protected]
> Subject: Re: ICE and TIPC
> 
> 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