RE: [Security400] Row level security

[rob@xxxxxxxxx]

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Yes.  Although I am having a dickens trying to figure it out.  You have to
get into the details of EDTOBJAUT (F11) to get it right.  I am just trying
to find the right combination.


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




"Andrew Lutz" <andrew.lutz@pmigroup.com>
Sent by: security400-admin@midrange.com
10/04/2002 10:16 AM
Please respond to security400


        To:     <security400@midrange.com>
        cc:
        Fax to:
        Subject:        RE: [Security400] Row level security


Your assumption is correct.

I have already attempted the approach # 1.  The result of which, the LF
is a pointer to data that exists in a file that I am not authorized to.
Did I miss something?

Approach #2, part of the requirement is we want to use 3rd party ad-hoc
query tools which would not work with stored procedures


-----Original Message-----
From: Buck Calabro [mailto:Buck.Calabro@commsoft.net]
Sent: Friday, October 04, 2002 7:08 AM
To: security400@midrange.com
Subject: RE: [Security400] Row level security

> This is what we want to do
> * One database
> * Most users (Companies) cannot view
>    each others information
> * Select users can view the entire database
> * Access to the files happens via all available
>   interfaces (i.e. not just green screen)

While the subject says 'row level security', the description sounds more
like you want to segregate Company A's data from Company B's users, etc.
Going on that assumption, the classic way to use OS/400 security to do
that
is to make AUT(*EXCLUDE) on the current PF and create an LF for each
company.  Grant authorised users authority to the logical (company) they
can
see, and OVRDBF after your selection to point to the 'right' one.

This presumes that user Buck doesn't need to see records from company A,
B
and C at the same time, but he can see them one after the other, viz.
Select
A, CHKOBJ, OVRDBF, see A.  Select B, see B.

Another way is to restrict all authority to the PF and create an API
that
all code must call in order to read the data.  The API validates that
the
user is able to access the record she is requesting.  That API can be
implemented as a stored procedure for the ODBC/SQL people, or as Scott
notes, a read trigger for V5R1.  That eliminates bulk transfers like FTP
and
Client Access.  The good thing about stored procedures on our platform
is
that the SP is an HLL program.  So the same program can serve green
screen
or SQL clients.

  --buck
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400)
mailing list
To post a message email: Security400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/security400
or email: Security400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.

_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400)
mailing list
To post a message email: Security400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/security400
or email: Security400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.