Re: CPYTOSTMF authority question -- MIDRANGE-L

Thanks Scott...
I am reading the help text on the AUTH parm of the CPYTOSTMF command...
*DFT: The owner of the stream file will be granted *RWX data authority to
the stream file. [check]
The primary group and *PUBLIC will have *NONE data authority to the stream
file [check].
Object authorities will be based on the object authorities for the
directory where the stream file is to be created[what? that directory has
*PUBLIC DTAAUT(*RWX) and OBJAUT(*ALL)] .

here is the Directory:
Work with Authority

Object . . . . . . . . . . . . : /mmail/temp/dcs03/
Type . . . . . . . . . . . . . : DIR
Owner . . . . . . . . . . . . : QUSER
Primary group . . . . . . . . : *NONE
Authorization list . . . . . . : *NONE

Type options, press Enter.
1=Add user 2=Change user authority 4=Remove user

Data --Object Authorities--
Opt User Authority Exist Mgt Alter Ref

*PUBLIC *RWX X X X X

On Fri, Sep 20, 2019 at 2:53 PM Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
wrote:

Hi,

The STMFAUT parameter defaults to *DFT. In older releases (sorry, I
don't remember when this changed) there wasn't a STMFAUT parameter, and
what you're seeing with *DFT was the only option.

*DFT results in the owner having *RWX, and group/public having *NONE.
Again, remember, at one time this was the only option.

I suspect that this is why the CHGAUT is being run, so that public has
authority to the file.

the problem I suspect from your description is that you're only doing a
CHGAUT for *PUBLIC, so the owner still has no object authorities and
therefore cannot use RMVLNK. Someone besides the owner would fall into
*PUBLIC, so would be able to delete it, but the owner still has
OBJAUT(*NONE) . You could add an additional CHGAUT to change the
owner's OBJAUT to *ALL to solve the problem.

-SK

On 9/20/2019 2:14 PM, Gerald Magnuson wrote:

it is NO....

we are aware of that attribute, as when we get a new box, and we do a
unload/reload... that attribute gets reset back to YES.....

On Fri, Sep 20, 2019 at 1:58 PM Rob Berendt <rob@xxxxxxxxx> wrote:

What is your target directory?
Without looking at the authority on the directory let's look at the
attributes of the directory. For example, by default, DSPATR '/tmp'

will

show that directory with
Restricted rename and unlink . . . . . : Yes.
As that is kind of a poor man's way of implementing how other open

systems

deal with that directory.
Most people change it to No. Otherwise email deletions do not happen
because when one job under one user, passes it off to the email job

under a

different user, the other user cannot delete it, even with *ALLOBJ
authority.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Gerald Magnuson
Sent: Friday, September 20, 2019 2:36 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: CPYTOSTMF authority question

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know
the content is safe.

I have found in tracing audit log problems, that we have been leaving
behind stream files that become email attachments....
CPYTOSTMF FROMMBR('/qsys.lib/qtemp.lib/mimeout.file/m+
imeout.mbr') TOSTMF(&STFILE) +
STMFOPT(*REPLACE) STMFCODPAG(*PCASCII)

this creates the stream file with the authority of DATA(*RWX) NO

OBJECT

AUTHORTIES for the user that ran the job.... we then perform a CHGAUT
OBJ(&STFILE)
USER(*PUBLIC) DTAAUT(*RWX) OBJAUT(*ALL) and then pass that stream file
onto MMAIL....

but at the bottom of the program, when we try to RMVLNK, it fails on
CPFA09C, not authorized...

I don't know for sure why we do the CHGAUT, but my guess was it allowed
the mmail command to process...

1) would a different value than "DFT on the AUT parm of the CPYTOSTMF
command fix this?
2) the original MIMEOUT file's authority a problem?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To

subscribe,

unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com