RE: field level security - (Was Use of a trigger...? ....) -- MIDRANGE-L

Rob, I don't think field-level security is available for read. Based on the
options on the GRANT statement in sql (as of V5R1) you can grant update
rights at field level but you can only grant select rights at file level.
Are you sure that field-level security includes read? Based on what you're
seeing in OpsNav I think is does NOT.

-Walden

------------
Walden H Leverich III
President
Tech Software
(516)627-3800 x11
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com



-----Original Message-----
From: rob@dekko.com [mailto:rob@dekko.com]
Sent: Friday, January 25, 2002 08:54
To: midrange-l@midrange.com
Subject: Re: field level security - (Was Use of a trigger...? ....)



CREATE TABLE ROB/RICHARD
(KEY1 CHAR (1 ) NOT NULL WITH DEFAULT,
FLD1 CHAR (1 ) NOT NULL WITH DEFAULT,
FLD2 CHAR (1 ) NOT NULL WITH DEFAULT,
FLD3 CHAR (1 ) NOT NULL WITH DEFAULT,
PRIMARY KEY (KEY1))

QCRTAUT is *CHANGE.

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?


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 08:18 AM
                    Please respond to
                    midrange-l







Rob,

RPG?  upstart?  stay away?  that IS funny!  on several levels.

How does field level security work now, using say, interactive SQL or
QRY400?  does it exclude the field from the list of available field names?
does it hard error out there too, if someone tries to use it without auth?

how would I have field level security behave?  I hadn't really thought about
it, but if the object is to hide and protect a particular field from
non-authorized users, maybe a better solution would be have the db return
null, blank or zero (you pick) on a read, and not allow update of the field.
a message written to the joblog (and/or qsysopr msgq) to inform those who
care about such things that access to the field was attempted and denied,
giving the user, job, program, line number.

I realize that this behaviour would have it's own problems and unintended
results, but so would a hard error.  If you're brave enough to implement the
feature, you should be smart enough to test it as well.

maybe I'm being dense here, but we already could "roll our own" field level
security by creative use of logical files and library lists.  what good is
the db2 version if we still have to create the same logicals, etc. so we can
use it in strait RPG?

rick

--- original message ---
It depends on how you define traditional.
Logical files have been around for a long time.
SQL has been around for a long time.
And I have a Systems Analyst text book from college that recommended staying
away from upstart languages like RPG.

How would you have had them handle it?

Rob Berendt

_______________________________________________
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.