Re: RCAC - Overriding Masked Values - was: Another FieldProc question -- MIDRANGE-L

Not so much documentation Rob as wishing that they had found some form of enforcement when RLA was being used. The only doc changes that might be useful would be to make the differentiation clearer.

Back in the olden days RPG/400 would ignore VarLen fields for example unless you "took control". I just wish that something similar had happened when RCAC was bought in. It just seems to me that not enough attention was paid to RLA during the design phase.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Sep 4, 2018, at 7:42 AM, Rob Berendt <rob@xxxxxxxxx> wrote:

Jon,

I'm starting to switch sides on this. Perhaps I've seen the light that
section 3.5 might have been dealing with row access control and not column
access control.
Birgitta's solution was mention in the original link I referenced:
https://www.redbooks.ibm.com/redpapers/pdfs/redp5110.pdf
in section "6.8 Avoiding propagation of masked data".

Where else do you suggest they put such documentation?

It was a healthy debate and did bring up some legitimate concerns. My
apologies to JHHL for not changing the subject when going off on a
tangent.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: "Jon Paris" <jon.paris@xxxxxxxxxxxxxx>
To: "Midrange-L Midrange-l" <midrange-l@xxxxxxxxxxxx>
Date: 09/01/2018 10:02 AM
Subject: Re: RCAC - Overriding Masked Values - was: Another
FieldProc question
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

I think you may be missing part of the point of the discussion Birgitta.

Your sample is very useful and is valid. I don't thin anyone is ignoring
that.

But it does not deal with the questions Rob raised about the apparently
contradictory nature of the documentation. The docs appearing to imply
that there is a level of protection available _without_ adding constraints
and that does not appear to be the case.

Nor does it deal with my concerns about the dangers of allowing new
functionality (RCAC in this case) with potentially harmful sideffects to
be added to existing tables with no requirement or warning that defences
such as the ones you explain so well are in place.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Sep 1, 2018, at 1:37 AM, Birgitta Hauser <Hauser@xxxxxxxxxxxxxxx>

wrote:

Nobody has read my answer before?

You need to add either a constraint with the ON VIOLATION Clause or a

SECURED trigger to your file with RCAC for avoiding the data is
overridden!

I a constraint with the ON VIOLATION clause or a SECURE trigger is added

to your table, even RPG native I/O will not override the value.

When debugging your RPG program and if you are not authorized to see the

masked value, you'll only see the masked value.

Here again a sample check constraint:
Alter Table YourSchema.YourColumn
Add Check (YourColumn like 'XXXX-XXXX-XXXX-%') -- compare with the

masked value

On Insert Violation Set YourColumn = Default
On Update Violation Preserve YourColumn;

And here a Sample Before Insert/Update Trigger
Create or Replace Trigger YourScchema.Replace_Mask_YourColumn
Before Insert or Update On YourSchema.YourTable
Referencing New Row as N Old Row as O
For Each Row
Mode Db2Row
Secured
When (n.YourColumn like 'XXXX-XXXX-XXXX-%')
Begin
If Inserting Then Set N.YourColumn = Default;
ElseIf Updating Tnen Set N.YourColumn = o.YourColumn;
End If;
End;

If you have a RCAC project the responsible for this project or your

database responsible has to plan and add the appropriate Check constraint
or trigger.

As soon as implemented the original values are NOT overridden and you do

not have to care about ANY program with NATIVE I/O or CPYF!

Just as an aside, when using CPYF is used for copy data or generating a

new file. The masked values and only the rows for which the user is
authorized are copied. RCAC Rules are not implemented on the new table.

When using CRTDUPOBJ an exact duplicate is generated with the unmasked

values and all rows. But also the RCAC rules are copied!

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars."

(Les Brown)

"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training

them and keeping them!"

„Train people well enough so they can leave, treat them well enough so

they don't want to.“ (Richard Branson)

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Peter

Dow

Sent: Freitag, 31. August 2018 20:35
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Another FieldProc question

I'll say. However, at least it didn't update it with the masked value,

i.e. masking is one-way. Of course as Jon Paris pointed out, if you had a
program that reads the record, then updates it without excluding that
field, then you'd update it with the masked value. A real landmine.

On 8/31/2018 9:55 AM, Rob Berendt wrote:

ROB sees the whole 234-56-7891, which makes perfect sense, based on
the masking.
What doesn't make sense is that DUMMY1 was allowed to change it.
Rather confused by the conflicting information in that redbook.

Rob Berendt

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,

visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a

moment to review the archives at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: http://amzn.to/2dEadiD

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: http://amzn.to/2dEadiD

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD