Experimental Physics and
Industrial Control System

Michael Abbott <[email protected]> · Mon, 30 Sep 2013 07:11:40 +0100 (BST)

Hi Andrew,

Let me strive not to make a mountain from a molehill, particularly as I 
only use the AS library to enable PV logging!  I don't really want to open 
the big box full of security issues...

On Fri, 27 Sep 2013, Andrew Johnson wrote:

> Hi Michael,
> 
> On 09/27/2013 02:57 AM, [email protected] wrote:
> > In EPICS 3.14.12 I am rather surprised to see the following warning
> > generated by asSetFilename:
> > 
> > asSetFilename: Warning - relative paths won't usually work
> 
> The asSetFilename command is not called asLoadFile; it merely stores the 
> filename to be used for the access security rules file, but does /not/ 
> cause the file to be loaded at the moment when the command is run.  The 
> rules file will first be loaded during iocInit, and can subsequently be 
> reloaded at any time after that by the user running asInit from the 
> shell, or by processing a subroutine record that calls asSubProcess(). 

Yes, I was wondering about the fact that the file isn't loaded straight 
away.

> Thus if you give a relative path to asSetFilename it will be applied 
> relative to the CWD at the time the file gets loaded.
> 
> This warning therefore is not there because other libraries may change 
> the CWD, it's because a console user may run a cd command in the shell 
> at any time after iocInit.  VxWorks and RTEMS only have a single CWD 
> which is shared by all threads — does anyone know if that is true of 
> Linux and/or Windows as well?  Can you guarantee that they/you will 
> never leave the IOC's CWD pointing to somewhere other than where the 
> developer was expecting it to be (and is that the iocBoot/iocXxx startup 
> directory, or some other location?).

Yes, I'm pretty sure the CWD is process wide.  Have to confess I am 
inclined to take the view that as soon as the user starts messing with 
state on the IOC command line, he gets to keep the pieces.  Still, I 
accept that unnecessary fragility is foolish.

> The consequences of a failure when reloading the access security rules 
> file is that the IOC turns off both read and write access to *all* PVs, 
> which is pretty drastic but when this system was designed it was felt 
> that this could be an indication that someone is trying to break into 
> the system.

Well, I did a quick experiment, and if the system can't reload the new 
security file it changes nothing -- this is noted in the comment above 
asInitializeOnce, and is also documented in the link you referenced.

If, on the other hand, we're really trying to protect against somebody 
trying to break into the system, and they've already got access to the IOC 
shell, well I don't know what to say!  As I said at the start, don't fancy 
opening this box.

> Thus giving asSetFilename a relative path results in unintuitive 
> behaviour, and could easily result in your control system shutting down.  
> Do you still think we should remove the warning message?  If you have 
> suggestions for improvements in the text I will be happy to hear them, 
> but I don't think it's possible to condense the above description into 
> anything meaningful.

Yes, I see the point.  What might be helpful would be a condensation of 
this point in a comment directly above the offending printf.  Certainly I 
went straight to the code, saw the rather unsightly test for an absolute 
path, laughed, and came straight here.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System