Re: field level security - (Was Use of a trigger...? ....)

[rob@xxxxxxxxx]

Crash on the trigger idea.  IBM must have been reefing on a bad one.  The
*read is only *after.  Must be for audit purposes only and not security and
other cool stuff.  You cannot change the data buffer or you get a nasty
CPF501B.

What a stupid limitation!

Not only does this thwart security, but let's say you have this erp package
which stores price in the file.  Well, rather than change all of the erp
programs to use an interactive pricing mod you could just put a read
trigger on the file to calculate price on the fly.

I will say the triggers are called even when you do DSPPFM - as well they
should be.  Would anyone out there have a problem if you could put a
trigger on your data to do either; a-security or b-calculated fields and
not see the actual data that is in the file?  I wouldn't.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    rob@dekko.com
                    Sent by:                  To:     midrange-l@midrange.com
                    midrange-l-admin@mi       cc:
                    drange.com                Fax to:
                                              Subject:     Re: field level 
security - (Was Use of a trigger...? ....)

                    01/25/2002 11:59 AM
                    Please respond to
                    midrange-l







As others have stated... Judging by the SQL  grant and revoke statements it
looks like you can only mess with update and references.  And it's not an
Op's Nav limitation.  (References is a referential integrity thing and
AS/400 developers don't care about that <but they should>.)

Maybe at lunch time I'll play with the trigger method of replacing the
field with *loval.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    "Richard B Baird"
                    <rbaird@esourceconsu       To:
midrange-l@midrange.com
                    lting.com>                 cc:
                    Sent by:                   Fax to:
                    midrange-l-admin@mid       Subject:     Re: field level
security - (Was Use of a trigger...? ....)
                    range.com


                    01/25/2002 11:13 AM
                    Please respond to
                    midrange-l







Rob,

Really!?   Did you try query? SQL?

Is there another way to implement FLS other than opsnav?  I've not had a
lot of experience with opsnav.  can you limit read authority first, before
the box is greyed out?

If this limitation is "working as designed", what's the point?  it seems to
me, the whole implementation is flawed.  what good does it do you if you
can't secure read authority?  Maybe this is why I've never seen or heard of
FLS being used.  too many limitations and quirks.

Has anyone on the list used field level security?
what are your experiences?

rick

--- original message ---
<snip>

Then I went into Operations Navigator and changed the security on FLD3 to
exclude the public.  When it came up I right clicked on the database and
selected permissions, clicked on details, clicked on columns.  There are
the following columns and there status:
Management - off
Alter - off - greyed out
Reference - off
Read - on - greyed out!
Add - on - greyed out!
Update - on
On FLD3 I turned update off.
Signed on as a peon.  They can see FLD3.  If they do UPDDTA then they can
see FLD3, they can change it but if they try to enter and save they get a
few messages, one of them being Not authorized to field FLD3 of file
RICHARD.  They can change other fields.

How do I secure read when the SOB is greyed out?

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





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