To deal with such conditions (several bits in ASGVAL), I changed my rules like this:
CALC("(A>>1)&1") CALC("(A>>2)&1") ...
Now I can have several rules giving a TRUE result
J.F. Gournay
CEA Saclay
IRFU/SIS
-----Message d'origine-----
De : Martin L. Smith [mailto:[email protected]]
Envoyé : jeudi 10 septembre 2009 14:03
À : GOURNAY Jean-Francois
Cc : [email protected]
Objet : Re: Access security problem
Now that you mention it you are correct, TRUE does correspond to 1 and
not > 0. The CALC must evaluate to 1 or 0 for this to work correctly.
I'm not sure what the logic is for this but it does seem to me that if
the CALC does not evaluate to 1 then it is FALSE.
I was thinking that it was the other way around and that the TRUE
condition meant != 0 rather than = 1.
With the right shift then what happens when the ASGVAL = 6?
When more than 1 bit is set you may need 2 conditions to evaluate the
CALC to TRUE. When you have 6 for example >>1 the value is now 3. I
think that you may need to get the CALC to evaluate to 1 to be TRUE.
Assuming of course that it will be possible your ASGVAL may be some
value other than 1,2,4, or 8.
Marty
GOURNAY Jean-Francois wrote:
> 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
>
>
>
- References:
- Re: Access security problem GOURNAY Jean-Francois
- Re: Access security problem Martin L. Smith
- Navigate by Date:
- Prev:
RE: sequencer feature request Mark Rivers
- Next:
Re: sequencer feature request Eric Norum
- Index:
1994
1995
1996
1997
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: Access security problem Martin L. Smith
- Next:
"buffer over-write" problem with StringIn record Maurizio Montis
- Index:
1994
1995
1996
1997
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
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·