RE: Restricting User Access

Booth,

Yes that's correct, even if the user has explicit authority to DFILE but
not ULIBRARY. Of course this doesn't apply if the user has *ALLOBJ
special authority.

Dave Kahn, TCO, Kazakstan
=========

kahn@tengizchevroil.com   (to November 25)
dkahn@cix.compulink.co.uk (from November 26)

>-----Original Message-----
>From:  boothm@ibm.net [SMTP:boothm@ibm.net]
>Sent:  Thursday, 20 November, 1997 05:49
>To:    MIDRANGE-L@midrange.com
>Subject:       Re: Restricting User Access
>
>on 11/18/97at 11:27 PM, the Great and Grand  Wazir John Earl
><johnearl@lns400.com> said:
>
>
>
The question about how to keep any user from getting at *PUBLIC authority
>
cuts right to the heart of the Client Access world.  If *PUBLIC has *USE
>
rights to an object, Client Access let's them read it, execute it, and
>
transfer it to their C: drive regardless of what your menu security says.
>
If *PUBLIC has *CHANGE, well you know where I'm headed....
>
>
Your idea about creating a separate library is a good one.  Be sure to
>
give the users only the access they need (*USE to programs, *USE or
>
*CHANGE to files as appropriate).  Client Access still must abide by
>
OS/400 object authority.  It's just that too often our object authority
>
is set too loosely.
>
>Now I have questions.  Do I understand this correctly?  If a data file
>named "DFILE" is in a library named "ULIBRARY"  and DFILE has *PUBLIC *ALL
>attached, but ULIBRARY has *PUBLIC *EXCLUDE  then any user not given
>specific authority to ULIBRARY can not access DFILE in any fashion,
>including Client Access and FTP?
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---