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

["Booth Martin" <booth@xxxxxxxxxxxx>]

--
--
[ Picked text/plain from multipart/alternative ]
My original question was about FERPA, which really has little to do with the
security issue.  In this instance, even the janitor can look up name and
address information, including Emergency Contact information,  The issue is
that if the individual has elected FERPA, then no one, including the
president, can relaese the information to outsiders.

The actual business rules aren't yet established because there is great
controversy going on as to what the regulations actually are, but the
consensus is that if an individual elects FERPA then the individual's
information can not be sold for mailing lists.  It also means we can't tell
the hospital the name of the individual's next of kin.

Therefore it appears my problem will be in alerting users when FERPA has
been elected, and more besides.  Simple denial of access is not a goal at
all.

--------------------------------------------
Booth Martin
MartinB@Goddard.edu
802-454-8315 x235
--------------------------------------------
-------Original Message-------

From: midrange-l@midrange.com
Date: Friday, January 25, 2002 08:18:38 AM
To: midrange-l@midrange.com
Subject: Re: field level security - (Was Use of a trigger...? ....)

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

_______________________________________________
--
[ Content of type unknown/unknown deleted ]
--