|
On Sep 4, 2018, at 10:05 AM, Rob Berendt <rob@xxxxxxxxx> wrote:
Actually I would think that many old school RPG programmers are not
those who would want to deal with RCAC in their programs directly. I
know one who retired before dealing with date/time or null capable fields.
Most likely RCAC would be implemented by someone more in the DBA
category, especially row access control. The way masking works, and
by adding the constraint, allows existing RPG programs to work as they
did before without change or recompilation. It's just getting more
important to read the small print on newer features.
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/04/2018 09:57 AM
Subject: Re: RCAC - Overriding Masked Values - was: Another
FieldProc question
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
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:column
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
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.constraints
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
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.added
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Sep 1, 2018, at 1:37 AM, Birgitta Hauser <Hauser@xxxxxxxxxxxxxxx>wrote:
SECURED trigger to your file with RCAC for avoiding the data is
Nobody has read my answer before?
You need to add either a constraint with the ON VIOLATION Clause or
a
overridden!
I a constraint with the ON VIOLATION clause or a SECURE trigger is
to your table, even RPG native I/O will not override the value.the
When debugging your RPG program and if you are not authorized to see
masked value, you'll only see the masked value.constraint
masked value
Here again a sample check constraint:
Alter Table YourSchema.YourColumn
Add Check (YourColumn like 'XXXX-XXXX-XXXX-%') -- compare with the
On Insert Violation Set YourColumn = Defaultdatabase responsible has to plan and add the appropriate Check
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
or trigger.do
As soon as implemented the original values are NOT overridden and
you
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 thevalues and all rows. But also the RCAC rules are copied!
unmasked
(Les Brown)
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars."
"If you think education is expensive, try ignorance." (Derek Bok)them and keeping them!"
"What is worse than training your staff and losing them? Not
training
„Train people well enough so they can leave, treat them well enoughthey don't want to.“ (Richard Branson)
so
Dow
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of
Peter
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 youa
had
program that reads the record, then updates it without excluding that
field, then you'd update it with the masked value. A real landmine.
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
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
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
listquestions.
Please contact support@xxxxxxxxxxxx for any subscription related
link: http://amzn.to/2dEadiD
Help support midrange.com by shopping at amazon.com with our
affiliate
list
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,questions.
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
link: http://amzn.to/2dEadiD
Help support midrange.com by shopping at amazon.com with our
affiliate
--
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
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,questions.
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
link: http://amzn.to/2dEadiD
Help support midrange.com by shopping at amazon.com with our
affiliate
--
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
