Re: Package Vendor that changes IBM command Defaults.

Roger,

Yikes!   These folks are out of control!

A couple of points are worth making.   First, by modifying critical pieces of 
the
operating environment they are opening your client's system up for every program
that is every compiled on that system.  Because AS/400's are typically 
muli-tuser
and multi-application platforms, this company is putting their customers boxes 
at
great risk.  If the customer has a program (not part of their package) that 
presents
the user with a command line, and you compile that program using a profile that 
has
some high level of authority, and then an end user did damage through the 
command
line because the program adopted authority,  would a court find that the vendor 
was
liable for the damage?  I don't know the answer, but I would bet it would be a 
good
fight.  I think this vendor ought to be given the opportunity to ponder their 
legal
culpability.

The second point to bring up is why does QSECOFR need to own anything?   Does 
the
application require that all users of the application be able to delete every 
object
on the system (*ALLOBJ special authority), create and delete user profiles 
(*SECADM)
and even alter storage and reconfigure ASPs (*SERVICE).  By running all 
applications
under QSECOFR authority they are giving _everyone_ who can access a command line
from the application the ability to completely hose the system.  And it is not 
for
the vendor to say who does and does not get access to the command line, you have
considerations in your shop that may make it necessary to provide the accounting
supervisor command line access.  That doesn't mean you want her running
communicaitons trace and deleting Audit journals.

The other problem that can occur with forcing you to use an IBM profile for
ownership is that profiles can fill up.  If a profile owns two many objects it 
runs
out of space to record it's ownership and then simply will not allow you to 
create
new objects under that profile.  If everybody makes QSECOFR the owner you could 
run
into this problem.

I understand that the vendor is _trying_ to do the right thing by creating an
Applicaiton Only Access sort of a system, (assuming that *PUBLIC has no rights 
to
all the applicaiton objects......   boy I sure hope that's true!).  But in 
order to
do this correctly, the vendor should provide their own (owner) user profile(s) 
that
has no special authority.  Using any IBM profile, and especially QSECOFR, 
provides
users of the package with all sorts of extra authority that they don't really 
need,
and puts data at risk.

Special Authorities within an application packageare seldom required.  In the 
few
instances that they are, a specific program can be crafted to adopt authority 
for
the specific purpose at hand.   Granting every program in an entire package the
ability to adopt QSECOFR is gross negligence, IMHO.

jte






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. I plan to explain to the vendor Wednesday morning how disastrous this
> can be, especially on a system where theirs is one of many packages plus
> multiple in-house development. Also, this is the WRONG way to make changes (to
> the QSYS library objects) even if they were justified. I doubt if they realize
> that anyone could Trojan horse one of their called programs to gain complete
> system access. Even if theirs was the only package on the box they have a
> payroll module which all this leaves wide open!
>
> <<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.
>
> Roger Vicker, CCP
>
> --
> *** Vicker Programming and Service *** Have bits will byte *** www.vicker.com
> ***
> We weld anything but the crack of dawn.
>
> +---
> | 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
+---