Re: Package Vendor that changes IBM command Defaults.

[John Earl <johnearl@xxxxxxxxxxx>]

James W Kilgore wrote:

> Roger,
>
> <<MODE(*REQUESTOR)>>
>
> As a software house, what can we do to provide a "painless" initial
> install or product upgrade?

The simple version is to use an Applicaiton Only Access design.  But now the 
one these
clowns have apparantly put together.  Create two owner profiles when your 
package is
installed, the first will own all the data objects and the second will own all 
the
program objects. Give *PUBLIC *EXCLUDE authority to the data objects and give 
the
Program Owner *CHANGE authority to the data objects. Then you can have some or 
all of
your programs adopt the authority of the Program Owner (thereby receiving 
*CHANGE
authority to the data) and grant specific users the rights to execute those 
programs.
Then you have a simple, clean authority system that will coexist nicely with 
other
packages that are on a system

> If you were in our shoes, what would you do/expect?  How are different
> security levels handled?

Write to Security level 40, and all lower security levels will work fine.   If 
you
write to 40 and the customer is running 10 or 20, then the security holes are 
their
fault, not yours.

> Do we ignore object security or roll our own? How do we deal with
> in-house security beyond our control that may interfere with our install
> script?

Don't ignore object authority, and don't try to roll your own (if rolling your 
own
means that you are somehow going to attempt to rewrite the rules of object
authority).  If you set the authority correctly in your package, and provide the
customer with a template on how to authorize users to your system  (Step 3, Add 
user
who should have access to the package to authorization list RUNPACKAGE), your 
package
will run fine on any system.  You just have to spend a little bit of time 
figuring out
wha the security requirements of your own package are, and then publish that 
for your
customers.

> Now I'm not ragging on you, but if your QSYSOPR has to create profiles,
> no can do.  It's beyond their profile authority. Install fails, you bad
> mouth software vendor.  Software vendor -needs- QSECOFR to create new
> profiles for secured ownership of objects.  Somewhere along the line a
> QSECOFR "like" profile has to come into play.

A QSECOFR like profile is often required at installation, but I can't imagine 
why it
would be required during day to day operations.


>  How about this: The software vendor provides a profile characteristic
> needed for installation and instructions necessary to create such a
> profile (QSECOFR alias QINSTALL) that you can disable after install?

That's fine.  No need to disable it after install, just don't use it.   There is
nothing the matter with requiring QSECOFR like authority at install time, but 
you
should not require it for run time.

> Bottom line: QSECOFR like profile -must- perform install/upgrade.

That's ususally the case.   I have no problem with that.

> Wait, I could be wrong.  The entire product is PUBLIC(*YES)
> OWNER(QDFTOWNER) or whatever is equivalent to an open barn door.

QDFTOWNER is actually preferable to QSECOFR if your package relies on adopted
authority.  That way the whole world doesn't end up sith special authorities.   
But
regardless of who owns it, *PUBLIC should only be authorized to things that you
wouldn't mind seeing published on the internet :)

jte

>
>
> You pick. I'll deliver either way.  After all, it's your machine. Your
> barn door. My lawyer can beat up your lawyer <g>
>
> Roger Vicker wrote:
> >
> > Hello,
> >
> > <<MODE(*RANT)>>
> > I have a customer where a vendor (name withheld to protect the GUILTY) for 
>one
> > of their packages, during a version upgrade, changed all the program create
> > commands to USRPRF(*OWNER) AUT(*ALL) and all the file create commands to
> > USRPRF(*OWNER) LVLCHK(*NO) AUT(*ALL). To top it off they compiled as a 
>member of
> > QSECOFR.
> <<snip>>
> >
> > <<MODE(*REQUESTER)>>
> >
> > What I would like, without creating a total flame war, is a FEW items from 
>this
> > esteemed group to show them as a backup to my lesson on how to play nicely 
>as a
> > software package vendor. I can accept the USRPRF(*OWNER) _IF_ the owner is a
> > special package owner and properly managed but definitely not QSECOFR!
> >
> > <<MODE(*HUMBLE)>>
> > Thanks In Advance.
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@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
> +---



--
John Earl                                              johnearl@toolnet.com
PowerTech Toolworks                         206-575-0711
PowerLock Network Security              www.400security.com
The 400 School                                    www.400school.com
--


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@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
+---