EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: EPICS Access Security - on screen basis
From: Matthias Clausen DESY -MKV2/KRYK- <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Fri, 23 Feb 1996 8:57:35 +0100 (MET)
Mark writes:

>Wouldn't an obvious solution/rejoinder be that when these screens are =
>created, you basically build some for the power (read/write) users; =
>different ones for the infidels, uh, rest of the world, and come up with =
>some compromise for the group that has limited access and so falls =
>somewhere between?=20

In fact this is something we also thought about.
But then - to avoid all the double work to support all screens twice( read and 
read/write screens) - we thought of an -in screen- password that will 
enable/disable write access to any record on this screen. This would help to 
solve the problem of:
- special read and read/write screens
- security for screens called up by any X-terminal
- flexibility to call up read/write screens on X-terminals you had not thought   
  of during configuration of your security databse

The password could be even an environment variable and/or a part of the screen 
configuration.
This mechanism is ment to me a safety feature to avoid undesired changes. The 
passwords does not necessarily have to be really secure. The operator should 
have to pass a 'barryer' before changing a value. 
To implement this we would need a 'password-button' which you press to pop up a 
box to enter the password. If write-access is not allowed all widgets should 
look like those where CA-security does not allow write access - a flag for all 
write-records on one screen.
We have good experience with this method. The operators know several different 
password to perform different actions like: 
tuning/editing/display-only/sequencing
This is implemented to avoid undesired changes in the system during night 
shifts.

In addition it would help if any write action to the IOC's could be logged on a 
file. This would help to keep track and analyse problems. This would need an 
output channel from the CA-server on the IOC to a (i.e.) NFS-mounted disk.
The output would look like:
date time user@machine changed record from value to value

Matthias

   Matthias Clausen		Deutsches Elektronen Synchrotron
					      DESY
			   Gruppe: MKS2/KRYK
			   Notkestrasse 85	    VXHERA::CLAUS
			 D-22607 Hamburg Bahrenfeld [email protected]
			   Tel: -49 40 8998-3256    [email protected]
			   Fax: -49 40 8998-4388    PSI%(0262)45050958002::CLAUS


Navigate by Date:
Prev: Re: Omissions in 3.12.2 Marty Kraimer
Next: Driver for Joerger VTR1012 Rainer Goergen
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Omissions in 3.12.2 Marty Kraimer
Next: Driver for Joerger VTR1012 Rainer Goergen
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·