× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I think I know the answer to this, but I need to ask.  If a program's
adopted authority is *OWNER and the owner is king-of-everything/*ALLOBJ
security officer, etc. etc., and that program updates a file that is
owned by PAYROLL user and has *PUBLIC *EXCLUDE on it, will the program
still update that file?

To expand on Larry's example, if a program with adopted authority
provides no access to a command line, can we consider ourselves "safe"?
In such a case, what happens when a user is in the middle of such a
program, and hits the Attn key to pull up Operational Assistant, hits
F9=Command Line, is the user still operating under the adopted authority
of the program he was in?

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------

> -----Original Message-----
> From: Larry Bolhuis [SMTP:lbolhuis@arbsol.com]
> Sent: Tuesday, August 21, 2001 11:00 PM
> To:   security400@midrange.com
> Subject:      Re: [Security400] Authority annoyances, continued...
>
> Dan,
>
> > That's why *I think* I like the USRPRF(*OWNER) approach with
> programs.
> > Sure makes it easy as it concerns authorization.  If I can run the
> whole
> > program without authority issues, then my worries are over by using
> > USRPRF(*OWNER).  Rhetorical question: Why not create all
> applications
> > this way?  Go ahead, scare me!
>
>   USRPRF(*OWNER) is the way to go here. The program is guaranteed the
> authority it needs and the user either CAN submit (or call) it or they
> can't.
>
>   Now why not do this all the time??? Well because unless you review
> the
> program carefully and know and understand EVERY caommand in there it
> could open a Mack Truck size secuirty whole in your system.  FOr
> example
> if a program adopting *OWNER owned by QSECOFR called some utility that
> had a command line option, the user just became King.  Or a Fkey that
> displays spool files, "Saaaaay, paychecks, this could be
> interesting..."  Just a couple simple examples!
>
>   - Larry


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.