RE: PTF 5770TC1-SI54738 and QSECOFR *USE

If I recall correctly, there is an authority granting command over /tmp that
the ESEND folks can provide you.

This looks vaguely familiar.

Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff
Crosby
Sent: Wednesday, October 01, 2014 11:45 AM
To: Midrange Systems Technical Discussion
Subject: PTF 5770TC1-SI54738 and QSECOFR *USE

All,

Yesterday morning about 7:20 we had a power outage that lasted 20-25
minutes. The UPS power handling program shut the System i 520 (V7R1) in an
orderly fashion. I had about 30 PTFs set to apply during an IPL, so they
did.

Later in the day I found that emails were not being sent from the IBM i. I
checked the joblog of the forwarding job of ESEND to see what was
happening. I found this error over and over:

CPF22E9 Escape 40 09/30/14 09:21:57.774322 QSYPHDL
QSYS *STMT QTMMSNDM QTCP *STMT
From module . . . . . . . . : QSYPHDL
From procedure . . . . . . :
validateUser__FPCcT1CcCiCUiiP18SYCB_UserProfil
e_TP14SYCB_GrpList_TPc
Statement . . . . . . . . . : 178
To module . . . . . . . . . :
QTMMSNDA
To procedure . . . . . . . :
QtmmSendMail
Statement . . . . . . . . . : 61
Message . . . . : *USE authority to
user profile QSECOFR required.
Cause . . . . . : When a password of
*NOPWD is specified, then *USE
authority to profile QSECOFR is
required. Recovery . . . : Have the
security officer issue the request
for this user profile or have the
security officer give you *USE
authority to user profile QSECOFR.

I looked through all the PTFs that were applied and 5770-TC1 SF54738 is the
only one that has anything to do with email. The cover letter contains:

DESCRIPTION OF PROBLEM FIXED FOR APAR SE60092 :
-----------------------------------------------
When using the SNDSMTPEMM command a MIME file is created in
/tmp. The APIs then send this MIME file. When it is created it
is created with an owner of either QMSF or QTCP, but then a swap
is done to the user that issued the command and this causes an
AF entry.

ESEND predates the SNDSMTPEMM command but I'm guessing it uses the same API
somewhere along the line. To get around the problem I granted PUBLIC *USE
access to QSECOFR, for now.

Does this seem to you that this PTF is the culprit? The description of
problem fixed does not seem an exact fit to me, it seems more the opposite
in that I wasn't getting authority failures before, but now I am.

I assume that PUBLIC *USE access to QSECOFR is not a good idea? Is it PMR
time?