Experimental Physics and
Industrial Control System

[email protected] (Deb Kerstiens) · Wed, 21 Feb 96 13:17:11 MST

Andy writes:

> I have some questions/comments on EPICS "Access Security":
> 
> (1) I wanted to see the effect of stopping a user from accessing
> data values with "dm", by using a suitably set-up access security file.
> It did work. However, I was somewhat surprised by the message returned in
> the "dm" text box which was "No data available". It was only when I looked
> at messages in my command tool that I realised that access was being denied.
> I don't see at present, how the user, just from looking at the "dm" screen could
> tell that access was being denied? Couldn't "dm" be made clever enough to distinguish
> the cases of "No data available" and "Insufficient Access"? At 14,000 ft 
> misleading messages will lead to even greater confusion when a system is
> being debugged!
> 
Andy raises a really good question here.  Yes, dm can know and inform the
user that there is a problem with access.  We haven't yet used access control
much at LANL, so I haven't had much input from users.  I'd like some input
from the user community as to what the needs/desires are in this arena.

There are a different access scenarios:
	read, write 
	read, no write 
	no read, write		(don't know how this one is implemented)
	no read, no write

What would be useful/appropriate in terms of handling these?  For example,
if someone creates a monitor on a channel that is read only, it seems to 
me that no extra action/information would be necessary.  If read access is
restricted, should a white box appear with "Insufficient Access"?  If a
controller is created on a channel with read/no write, I'm guessing it
makes sense to display the value but indicate the problem if someone tries
to make a change.  I was planning to just indicate with the form of the cursor
that it is not writeable.  Would it be preferable to have a popup dialog
in addition (or instead of) the cursor change?  If a controller is not
readable, again use the white box with "Insufficient Access"?
What about dynamic graphics?  Should I use the same white box to indicate 
insufficient access or just not have it show up?  (My preference is to
indicate it.)  Another question: what about color rules.  If one can't
access a channel(s) upon whose value(s) the color rule for that object
depends, how should that be indicated?  Currently, if a color rule can't
be resolved, the color of the object is white.  Is that sufficient or
should there be more explicit information indicating that read access
is involved?

I'd like to have input asap from those of you using edd/dm who have a
vested interest in the outcome.

BTW, I also think it would be good to address the broader issue of what kind 
of actions are taken and/or information given relating to access control for 
EPICS base and tools in general.  It might be nice to be as consistent as 
possible (and to document what the expected behavior is.) 

Deb

p.s.  FYI, the "No data available" message indicates that a connection was
successfully made, but that dm did not receive the data from a monitor
request for that object.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System