Experimental Physics and
Industrial Control System

Sorry, I still think I am right !

I run my tests on a soft Linux IOC. The asDumpRules cmd seems to be asprules in my case. Here are my results with A=1 and A=2 following Andrew’s suggestion (A& … instead of A >> …).

With A=1 the 1rst RULE for WRITE is TRUE which is OK

With A=2 I A&2 = 2 which is NOT the TRUE value (TRUE corresponds to 1 and not to !=0):

 

Simulateur >

Simulateur >dbpf ASGVAL,1

DBR_LONG:           1         0x1                

Simulateur >asprules

ASG(DEFAULT) {

        INPA(ASGVAL) value=1.000000

        RULE(1,READ,NOTRAPWRITE)

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(tous)

                HAG(hag)

                CALC("A&1") result=TRUE       

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(develop)

                HAG(hag)

                CALC("A&2") result=FALSE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(physique)

                HAG(hag)

                CALC("A&4") result=FALSE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(gournay)

                HAG(hag)

                CALC("A&8") result=FALSE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(epics)

                HAG(hag)

                CALC("A&16") result=FALSE

        }

}

Simulateur >dbpf ASGVAL,2

DBR_LONG:           2         0x2                 

Simulateur >asprules

ASG(DEFAULT) {

        INPA(ASGVAL) value=2.000000

        RULE(1,READ,NOTRAPWRITE)

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(tous)

                HAG(hag)

                CALC("A&1") result=FALSE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(develop)

                HAG(hag)

                CALC("A&2") result=FALSE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(physique)

                HAG(hag)

                CALC("A&4") result=FALSE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(gournay)

                HAG(hag)

                CALC("A&8") result=FALSE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(epics)

                HAG(hag)

                CALC("A&16") result=FALSE

        }

}

Simulateur >

 

If now I change the 2nd rule from A&2 to A>>1, I have now TRUE:

 

Simulateur >dbpf ASGVAL,2

DBR_LONG:           2         0x2                

Simulateur >asprules

ASG(DEFAULT) {

        INPA(ASGVAL) value=2.000000

        RULE(1,READ,NOTRAPWRITE)

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(tous)

                HAG(hag)

                CALC("A&1") result=FALSE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(develop)

                HAG(hag)

                CALC("A>>1") result=TRUE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(physique)

                HAG(hag)

                CALC("A&4") result=FALSE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(gournay)

                HAG(hag)

                CALC("A&8") result=FALSE

        }

        RULE(1,WRITE,NOTRAPWRITE) {

                UAG(epics)

                HAG(hag)

                CALC("A&16") result=FALSE

        }

}

 

J.F. Gournay

CEA Saclay

IRFU/SIS

 

-----Message d'origine-----
De : Martin L. Smith [mailto:[email protected]]
Envoyé : jeudi 10 septembre 2009 12:50
À : GOURNAY Jean-Francois
Cc : [email protected]
Objet : Re: Access security problem

 

Actually Andrew is correct. Take the "A&2" as an example, when bit 1 is TRUE

then the result of the CALC is TRUE, when bit 1 is FALSE then the result of

the CALC will be FALSE. TRUE being = 1 and FALSE being = 0.

 

This may be why you are seeing this problem. If you log into the IOC console

and issue this command you will see the value that CA access security thinks

your CALC _expression_ evaluates to as shown below.

 

asDumpRules

ASG(ID01ds_ACTION) {

         INPA(ID01ds:AccessSecurity) value=3.000000

         RULE(1,READ,NOTRAPWRITE)

         RULE(0,WRITE,TRAPWRITE) {

                 UAG(operator)

                 HAG(local)

                 CALC("A<3") result=FALSE

         }

         RULE(0,WRITE,TRAPWRITE) {

                 UAG(flcord)

                 HAG(flctrl,local)

                 CALC("A<2") result=FALSE

         }

         RULE(1,WRITE,TRAPWRITE) {

                 UAG(sec01)

                 HAG(sec01)

                 CALC("A<1") result=FALSE

         }

         RULE(1,WRITE,TRAPWRITE) {

                 UAG(appdev)

         }

}

 

Marty

 

 

GOURNAY Jean-Francois wrote:

> Dear Andrew,

>

> I think you are wrong. Remember that the CALC _expression_ must return TRUE or FALSE which will not be the case with A&2, A&4 ...

> I guess my scheme is correct. Everything works except this problem with this spiral2mgr user that I don't understand (see the table below from my previous mail). We will try to overcome it in a way or another ... unless somebody has another idea about it !!!

>

> J.F. Gournay

> CEA Saclay

> IRFU/SIS

>

> -----Message d'origine-----

> De : Andrew Johnson [mailto:[email protected]]

> Envoyé : mercredi 9 septembre 2009 16:56

> À : [email protected]

> Cc : GOURNAY Jean-Francois

> Objet : Re: Access security problem

>

> On Wednesday 09 September 2009 07:34:52 GOURNAY Jean-Francois wrote:

>> I did more systematic tests and I have this strange situation:

>> 

>> ASGVAL  UAG      spiral2  spiral2mgr      gournay

>> 

>> 1       tous      W        W               W        OK

>> 2       develop   -        - (should be W) -        WRONG

>> 4       physique  W        -               -        OK

>> 8       gournay   -        W (should be -) W        WRONG

>> 

>> W : database WRITE access

>> - :  no write access

>> 

>> I modified the CALC expressions accordingly to Martin suggestion :

>> CALC("A&1") instead of CALC("A&1=1").  But I don't think I have to write

>> CALC (A>0&&A<2) as my A value comes from a longout record.

>

> You're right there, but for historical reasons the relative precedence of

> the ">>" and "=" operators are different in C and CALC, so you do need to

> change your expressions:

>

>>             CALC("A&1=1")

> As Marty suggested "A&1" is sufficient here

>

>>             CALC("A>>1=1")

> CALC actually evaluates this as "A>>(1=1)" which is not what you mean.  You

> could use "(A>>1)=1" but I would suggest "A&2" here instead.

>

>>             CALC("A>>2=1")

> "A&4"

>

>>             CALC("A>>3=1")

> "A&8"

>

> Using fewer operators will also parse and execute faster.

>

>> This message sent yesterday didn't show up.

>

> That's because you actually sent it to tech-talk-bounces@aps., not to

> tech-talk@aps., and I didn't get a chance to forward it manually before you

> re-sent it.

>

> HTH,

>

> - Andrew

 

 

 

J.F. Gournay

CEA Saclay

IRFU/SIS