When a PHP script writes a new file to the IFS, the object authorities for the owner of the file may not be what the author of the script expected. Subsequent operations performed on the new file may fail because the owner does not have the expected object authority. This article tells how the owner's object authorities are assigned to new IFS files. This information can help insure that new files have the needed permissions.
All versions of IBM i.
This information was taken from a document published by IBM Support:
This is a very good document to read to understand the ins and outs of authorities on the IFS. I recommend it highly. Go read it now, if you can. You can also find much of the same information in this documentation page:
Data authorities and object authorities are listed below, but just briefly things you cannot do to an object without the proper object authorities include delete, move, and rename. There are more, but these are the kinds of things most folks are surprised they cannot do to an object using the object owner's profile.
The owner of an IFS file is NOT automatically given the object authorities. They have to be granted somehow. When a new file is created, the creator is typically the owner, but the owner's object authorities are assigned in a kind of strange way.
The object authorities given to the owner of a new file are the same as the object authorities given to the owner of the containing folder, even if that is a different profile.
This is a little different than what some of us (myself included) might imagine. We might imagine that whatever object authorities the new file owner has in the containing folder would apply to the new object. We could not be more wrong.
Consider this example, basically copied from the above IBM document, but altered a bit to be more applicable (we use QTMHHTTP instead of BOB).
Here are the object authorities for a directory called /rjzeller:
You will recognize the QTMHHTTP profile as the default Apache profile that often is the profile running PHP scripts. Imagine a PHP script writes a PDF file called mydoc.pdf into this directory. PHP was running as QTMHHTTP when the PDF was created, so QTMHHTTP owns /rjzeller/mydoc.pdf. A subsequent script attempts to delete /rjzeller/mydoc.pdf, but gets an error. Why?
This is because RJZELLER, the owner of /rjzeller, does not have any object authorities to /rjzeller. They were never granted. So, the owner of any file created in /rjzeller will not have any object authorities to that file. In this case, the owner of /rjzeller/mydoc.pdf is QTMHHTTP, and so QTMHHTTP has no object authorities to the file, despite being the owner. Even though QTMHHTTP has all object authorities to the containing folder /rjzeller, it does not matter. It only matters what object authorities RJZELLER has to /rjzeller, because RJZELLER is the owner of the folder.
So, with no Exist authority, QTMHHTTP is not allowed to delete the /rjzeller/mydoc.pdf file, and the PHP script fails.
To avoid this situation, the owner of /rjzeller could be given all object authorities to the /rjzeller folder:
Any new files created in this folder will have all object authorities granted to their owners. So, if QTMHHTTP creates a file in this folder, QTMHHTTP will be able to delete, rename, or move the file later. This is the typical expected behavior.
Some basic descriptions of the authorities, copied out of the help text for the WRKAUT command: