RE: Can We retire the QSECOFR userid?

Rick,

As mentioned in a previous post, you can adopt the authority of a
profile with the necessary authority (including special authority),
that's fine.  Just don't force your users to sign on with exactly the
"QSECOFR" profile.  If you do a RTVUSRPRF and check for the appropriate
special authorities, you'll do just fine.  If you know that your
application needs *SPLCTL, or *IOSYSCFG, or even *ALLOBJ, then it's OK
for you to insist that the user of your application either has, or
adopts, this authority.   

Also, it's not unusual for a vendor to create one or more user ID's as
part of their install routine, endow those ID's with selected special
authorities, and use those ID's as the owner of programs that adopt
authority.  We advocate for the judicious use of powerful authorities,
not the total outlaw of them.

jte





--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Rick Renkema
> Sent: Sunday, February 08, 2004 1:48 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: Can We retire the QSECOFR userid?
> 
> > <snip>
> > 2.           If some stupid software vendor hard-codes
> into their
> > product that you must use "QSECOFR" to install or change
> > something (It happens, but still, this should be a rare
> > event.  And with the right software vendors, it may
> never
> > happen).
> > </snip>
> 
> OK ... guilty ... I am a lazy, good for nothing software
> developer, that
> forces you to install with QSECOFR.
> Since no other software developer has (in my memory)
> admitted this on the
> list (4+ years I think) I am happy
> to parade my ignorance before you.  I am expecting you to
> educate me, 'cause
> I cannot find anything better in
> any manuals I have had the time to pour over in the past
> (and people I have
> spoken to).
> /EXPECT PARM(ABUSE) *** And it is so easy to use QSECOFR.
> /RUN PARM('DEVIL' 'ADVOCATE')  *** My insurance, go easy
> on me.
> 
> If you don't want to use QSECOFR, don't buy the software.
> But if you buy the software, and you want to use it as
> intended, then
> perhaps sometimes it is necessary.
> Correct me if I am wrong.
> 
> Security on the AS/400 is first class, down to object
> level.  Spooled files
> (my baby in a previous life) can be
> stopped from printing if the person printing does not have
> the correct
> authority.  My, I can even stop you
> from accessing a spooled file queue and therefor stop you
> from viewing it.
> 
> Believe it or not, businesses buy software to print
> spooled files.
> They also buy that software because it may have the
> ability to do some
> management on the 400 - spooled
> file specific, like copying to another queue for
> distributed printing
> processes.  Now while all this sounds terribly
> simple (and it is really), there are some matters that
> require close
> attention.  The security levels needed for the
> Create spooled fileAPI, open spooled file API etc stop the
> software from
> reading the spooled file if the security isn't
> high enough to allow that operation.  How many of your
> plebiscite Id's have
> *SPLCTL ?  Who starts the IBM writer ?
> What security is on the writer ?  Can Joe Bloggs start the
> writer for the
> warehouse (picking slips) at 5am,
> and the office for invoices at 5am ?  If so, does your
> Sales manager want
> his reports from the same printer
> in the office at 10am ?  Does Joe Bloggs have that
> authority ?  How many
> times have I fallen in a heap because some
> of the thousands of customers that run this software have
> different
> approaches to security.  How easy it is to use QSECOFR.
> 
> Oh, and it adopts that authority too (I'm digging my grave
> here).  Because
> the Sales manager will want to see his report,
> regardless of who started the writer, regardless of the
> authorities
> associated with the queue.  You put something there to
> print it.
> If you had the authority to put it there in the first
> place, or if you had
> the authority to move it there, or copy it there,
> then why should I take your abusive phone calls if my
> software (supposedly)
> doesn't work because it is not printing
> your spooled file ?
> 
> Now please, this is my personal opinion, my personal
> experience.  Don't
> punish my company (-ies) for what I say.
> I was going to leave my addresses off ... but then, some
> may want to abuse
> me in private.
> I get disillusioned by the number of times some people on
> this list tear
> shreds of every software developer that
> forces you to use QSECOFR for an install.  It's easy to
> complain (I hear it
> every day), compliments are few
> and far between - But if you have 3000 installs and 10
> complain about
> QSECOFR, I believe I did OK -
> unless YOU have a better idea ...
> 
> In the words of Alec McGuiness in Bridge over the River
> Kwai : "What have I
> done ?"
> 
> Regards,
> 
> Rick Renkema
> iSeries Developer
> Mid-Comp International Pty Ltd
> Phone : +61 3 9011 8288
> Fax : +61 3 9544 9631
> Mobile : +61 (0)414 877 483
> email : rickr@xxxxxxxxxxxxxx
> 
> "All great discoveries are made by mistake"
> 
> 
> _______________________________________________
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.