Re: Doubts on permissions of files created in the IFS

That behavior is exactly what I would expect. Since USER1 has a specific
authority (in this case OBJAUT(*NONE) that overrides the *PUBLIC authority.
Your solution is what's needed.

Adopted authority does not work as expected with the IFS, so the best
solution is the one you are using, or, change the parent directory since
the child directory is inheriting some of the security aspects. Presuming
that to no be reasonable, then you are back to the grant/remove process.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On Wed, Apr 12, 2023 at 9:01 AM Fabio Mascelloni <fabio.mascelloni@xxxxxxxxx>
wrote:

Hi everyone,
I've an RPG progam that downloads stream files into the IFS from an
external FTP server (calling a CL program), processes them, then should
delete them.
Suppose the program runs under user profile 'USER1', the program creates
stream files with 'USER1' as the owner and the following permissions:

DTAAUT(*RWX) and OBJAUT(*ALL) for *PUBLIC
DTAAUT(*RWX) and OBJAUT(*NONE) for 'USER1'
DTAAUT(*RWX) and OBJAUT(*NONE) for 'QPGMR'

The program is not able to delete the files downloaded (error '3401')
unless it issues a CHGAUT on the file to revoke all permissions from
'USER1' or give it permissions to before trying to delete the file.

All dirs in the path where fles have permissions DTAAUT(*RWX) and
OBJAUT(*ALL) for *PUBLIC

I've never been good with permissions, please help me figure out what's
wrong...

Thank you,
Fabio.

--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.