Re: Package Vendor that changes IBM command Defaults.

Roger,

In a message dated 6/22/99 1:06:17 AM Eastern Daylight Time, 
rvicker@vicker.com writes:

> <<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.

Scrap them and get your money back, or sue them.  This is unacceptable 
conduct.  Even the (arguably) "industry standard" Help Systems has been 
lambasted here in the past for things like placing libraries in the system 
portion of the library list with its Robot product without informing the 
customer or offering them an alternative.  A vendor that truly understands 
the AS/400 and the security implications of this sort of thing would NEVER 
resort to these sorts of methodologies.

> 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!

You shouldn't _HAVE_ to explain this although, to my knowledge, Help Systems 
didn't take the hint from the bath they took here previously -- even though I 
know they monitor this list.  There is _NO_ justification for the 
modification by a vendor of system values, authority settings on already 
installed objects, or command defaults, IMO.  Several vendors, including my 
personal favorite, do this without regard to the consequences.  Trojan horses 
are the _least_ of your problems -- people with access to your system that 
know this package and what it does could do more damage to your AS/400 in 10 
seconds than a "Trojan Horse" could do in ten years.

>  <<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.

MODE(*SERIOUSASAHEARTATTACK)

Adding library list entries, changing command defaults, and messing with 
system defaults are completely unnecessary.  Some suggestions:

1.  If you MUST have specific libraries for your application, create data 
areas pointing to the proper libraries within your application that are 
changed during install to point to the libraries that were actually 
installed.  Then qualify your programs/commands based upon these data areas.

2.  If you need to change command defaults, duplicate the commands out of 
QSYS into QTEMP during install and CHGCMDDFT there.  Qualify the commands to 
your changed version in QTEMP.

3.  If you follow 1 and 2 and have a well written package, changing system 
defaults should not be necessary.

Frankly, security matters have been given short shrift around here of late.  
I don't know if this is because of IBM's correction of most of the matters at 
the system level with which we were concerned a few years back, a more 
knowledgeable user base, or a genuine lack of knowledge among the newcomers.  
It certainly _IS NOT_ because of better vendor implementation of security.  
We used to get two or three posts from Steve Glanstein (our Hawaiian security 
advocate) per week, now we rarely hear from him.  Perhaps more issues like 
this should be raised...

Regards,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-mail:  DAsmussen@aol.com

"Who would ever need more than 640K of memory and a 30 meg hard drive?" -- 
visionary Bill Gates
+---
| 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
+---