Re: Library Authority

Personally I don't find the separate library thing such a big hassle.
1 - Name the LF library higher in the alphabet than the pf library.  So if 
your PF library was MYLIBF then name your lf library MYLIBFLF.  Then in a 
complete unload/reload the PF's will all be there.
2 - If someone violates this, or if they do stuff like have a LF in LIBA 
pointing to a PF in LIBB and a LF in LIBB pointing to a PF in LIBA then I 
still wouldn't stress out.  When restoring I simply do a second RSTLIB 
*NONSYS with the OPTION(*NEW).  There's even some obscure reference to 
this in the Backup and Recovery Guide.  Having done an unload/reload 
within the last month it was no problem. 

I've got real issues to get stressed over instead of being concerned with 
cross library logicals. 

Hey, if my boss found that easy solution, and he hasn't written a program 
in way over a decade...

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Mike <[email protected]> 
Sent by: security400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]
08/14/2008 05:21 PM
Please respond to
Security Administration on the AS400 / iSeries  <security400-Zwy7GipZuJhWk0Htik3J/[email protected]>


To
"Security Administration on the AS400 / iSeries" 
<security400-Zwy7GipZuJhWk0Htik3J/[email protected]>
cc

Subject
Re: [Security400] Library Authority






I hear what you are saying, but by leaving it in that library the users
start browsing other files in the library and get curious. We are 
excluding
that new library from being saved because all it has is the logical views
for Crystal Reports. Those can be rebuilt easily from the saved source and
are non-critical.

I'll put it this way, we need to do a overhaul of our whole system so it 
can
be better locked down. We are applying band-aids to fix the immediate
problems that we currently have. The overhaul project might move up in the
priority list now but has currently been on the to-do list for years.

-- 
Mike Wills
Midrange Programmer/Analyst

Sick of corporate radio and hungry for something new?
http://thenextgenerationofradio.com
Stalking me? http://twitter.com/MikeWills | 
http://friendfeed.com/mikewills


On Thu, Aug 14, 2008 at 3:27 PM, CRPence <CRPbottle-/[email protected]> wrote:

>   If possible, separate libraries for logical files should not be used
> to secure the data.  Doing so complicates save/restore and disaster
> recovery.  Instead of giving *USE to the PF, grant only *READ, and Then
> give only *USE to the LF.  Leave both the PF & LF in the same library.
> That accomplishes the same thing, without two libraries.
>
>   Also the claim that more authority than the PF can not be given to
> the LF, is misleading.  As many rights may be granted as are available,
> i.e. up to *ALL.  The data rights from the LF however, can not override
> the PF data rights that are available to the user accessing the LF.
>
> Regards, Chuck
>
> Mike wrote:
> > Jim Franz wrote:
> >>
> >>  <<SNIP some of quoted text and reply>>
> >>
> >> Mike wrote:
> >>>
> >>> Also, if we have *EXCLUDE on a library. Then we have a logical in
> >>> another library pointing to a file within the secured library.
> >>> Would that work? The file in the locked library would have READ
> >>> access only.
> >>>
> >> yes - (i've not tested this), note: data authorities on LF cannot
> >> be more than on PF. (this one i was not positive till checking
> >> Woodbury/Botz's Experts Guide book p164)
> >
> > I did just try this one and it works.  I give the READ data authority
> > only on the PF in one library with *EXCLUDE on the library, then give
> > them *USE access on the logical on a separate library. Now we can
> > control what live data they can access and what data within the file
> > they can access.
> >
> > I'll have to look into that book more.
> _______________________________________________
> This is the Security Administration on the AS400 / iSeries (Security400)
> mailing list
> To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/security400
> or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
> 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-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
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-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.