|
I attached a .txt file on IFS Authority consideration. I think it might help answer your question and maybe even more. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Pete Helgren Sent: Friday, September 09, 2005 8:30 AM To: Midrange Mailing List Subject: File permissions on a file upload I posted this on the WEB400 list yesterday but got no takers on an answer. Perhaps I can rephrase this so it is applicable to Midrange-L. How do IFS file permissions get set? Below is my post to WEB400 where files are uploaded to the IFS. The application can list the file, providing a link for the user to open the file, but when the file is opened (or attempted to open) I get an access denied message. Perhaps an idea on how to monitor for files placed in this folder and then a program that grants READ permissions? That seems a little awkward but I guess that would be a possibility. Don't files placed in an IFS folder "inherit" the folder permissions? Is there a way to do this? The rest of the post is what was on WEB400: Any idea how permissions can be set for files uploaded through a web page to the IFS? We are running PHP in PASE and the file gets created with the following permissions: Data --Object Authorities-- User Authority Exist Mgt Alter Ref *PUBLIC *NONE X X X X QTMHHTP1 *RW X X X X If we change permissions to *PUBLIC *R then we can access the file. There was a solution in the archives for Apache/Websphere but it doesn't apply to a PHP server. Any idea of how you could accomplish the change of permissions? Since *PUBLIC has *RW permissions on the folder I thought files copied to that folder would inherit those permission but I guess I assumed too much. Ideas? Thanks, Pete Helgren
midrange.com
IFS Authority Considerations
Adopted authority is not supported by the Root ('/'), QOpenSys, and
user-defined file systems.
Many operations require *RX athority to the entire path including the root.
When experiencing authority problems, verify the entire path including the
root rather than only the object and its immediate parent.
Files created with the CPYTOSTMF or CPYTOIMPF commands have data authorities
for *PUBLIC set to *NONE and have no group authority regardless of the
authorities on the parent directory. The CHGAUT command must be used after the
CPYTOSTMF or the CPYTOIMPF command fails to assign the desired authorities.
To retrieve authority information about an object, the user must have *OBJMGT
object authority to the object. This can affect functions such as COPY which
needs to retrieve authority information about the source object so it can set
the equivalent authorities on the target object.
The user changing the owner or group of an object must have sufficient
authority to the object; for example, *ADD data authority to the new
owner/group user profile and *DELETE data authority to the old owner/group.
These are not the same as the file system data authorities. This can be viewed
using the DSPOBJAUT command or the EDTOBJAUT command. This can be an issue on
some COPY commands when trying to copy the group.
When changing the owner or group of an object, the new owner cannot be the same
as the current group, or the new group cannot be the same as the current
owner.
To display or retrieve the current working directory (DSPCURDIR, GETCWD(), and
so on), you must have *RX data authority to the whole path including Root. To
change your current directory (CD, CHDIR(), and so on), you need only *X
authority to the whole path. This means that you can change your working
directory to a path that you are unable to retrieve.
To change the group of an object, the user must be a member of the new group.
Therefore, if the source object of a CPY has a group and the target directory
has no group or a different group, the user performing the CPY must be a
member of the group for the source object. If not, the user is not authorized
to change the group on the newly created copy and an authority failure occurs.
In UNIX environments, users and groups are separate entities. On the AS/400e
or iSeries system, however, they are both the same object type (all a type
*USRPRF object). The only difference is that a user profile with a group ID is
considered a group profile. However, OS/400 security still recognizes the
difference. For example:
Object . . . . . . . . . . : /rjzeller
Owner . . . . . . . . . . : RJZELLER
Primary Group . . . . : RJZGRP
Authorization List. : *NONE
User authorities are set with *PUBLIC to *EXCLUDE, RJZELLER all authorities
(*RWX and all object authorities), and RJZGRP all authorities (*RWX and all
object authorities). If RJZGRP were to sign on, RJZGRP would not have any
authority to '/rjzeller', even though it appears that it has all authority to
the object. The listed authority applies only to the members of the group
RJZGRP, not to the user RJZGRP. Additionally, you cannot change the group for
a "group profile" to itself; that is, the user RJZGRP cannot make RJZGRP a
member of group RJZGRP. If the primary group was changed to *NONE and a
private authority was added for user RJZGRP, user RJZGRP would have access to
the directory. Members of RJZGRP would also have access, because RJZGRP is
acting as an AS/400 (iSeries) group profile, not as a UNIX group. This would
seem to indicate there is an advantage to simply assigning a private authority
for group profiles rather than assigning a group ID for an object. However,
private authorities are often not propagated to objects created in a directory.
The group always is, though different data authorities may be assigned.
Therefore, assigning a primary group to a directory when it is first created
will ensure that all objects created in that directory tree will also have that
primary group when they are created.
Initial object authorities are assigned to a new file or directory based on the
authority values of the parent directory. The following rules involved with
this are:
a) The owner for the new object has the same object authorities the owner of
the parent directory to the parent directory.
b) The primary group for the new object the same object authorities the
primary group of the parent directory to the parent directory.
c) *PUBLIC has the same object authorities to the new object that it has to
the parent directory.
These rules apply even when the owner of the parent directory and the newly
created object are not the same, and even when the owner of the new object has
separate private authority to the parent directory. For example:
Object . . . . . . . . . . . . . . : /rjzeller
Owner . . . . . . . . . . . : RJZELLER
Authorization List. . . . . : *NONE
User: Object Auth:
Object authorities -
*PUBLIC *NONE
BOB *ALL
User BOB signs on and creates a new object (file/dir) under /rjzeller. BOB is
the owner of this new object and adopts the same object authority as the owner
of object '/rjzeller'.
Because RJZELLER does not have authority to '/rjzeller' (no user authorities
are listed for RJZELLER), user BOB also does not have object authority to the
object he created under '/rjzeller'.
This can be a problem for some PC applications (such as Excel/Word) which
create a temporary file when opening a current file for edit. When the user
attempts to save the file, the application renames the temporary file to the
original file name; however, this requires at least *OBJMGT authority which the
owner does not have (example above) and, therefore, the user is unable to save
the file.
The above is true for OBJECT authorities. DATA authorities are handled
differently. Typically, how these are inherited or determined are based on the
interface used to create the new object. From most PC interfaces, the
owner/creator gets all data authorities regardless of the parent authority.
The MOV command requires special considerations:
Consider '/DIRA/FILEA' which is owned by user USERA; if USERB copies FILEA to
'/DIRB', then '/DIRB/FILEA' is owned by USERB. But, if USERB moves FILEA to
DIRB, '/DIRB/FILEA' should still be owned by USERA. In both cases, private and
group authorities should be the same on the target as on the source.
This is usually fine when the MOV involves linking the object to the new
directory and unlinking it from the old one. No authorities are retrieved or
changed, and conflicts are limited to the object and the source and target
directories.
However, when crossing file-system boundaries or doing text conversions (or any
operation which does not support a true MOVE) the MOV operation becomes a
copy-and-delete operation. In the copy portion, the target object must be
created. At this time, the object is owned by the user performing the MOV
(USERB). The data is copied. Then the attributes are read from the source,
including the authority attributes (which requires *OBJMGT). Then the
attributes are set on the target. This includes (in order) changing the
private authorities, changing the group, and changing the owner. Since USERB
owns the new object, USERB can set the private authorities with no trouble.
But suppose that USERB happened to be the group profile for the source object?
The new object is owned by USERB and now it wants to set the group to USERB.
The MOV fails.
Or, suppose that the group on the source object was GROUPA and the target
object was created with an initial group inherited from its parent (GROUPB).
USERB requires *ADD data authority to GROUPA and *DELETE data authority to
GROUPB (these are the data authorities to the *USRPRF objects). USERB must
also be a member of GROUPA.
We now want to set the owner. USERB requires *DELETE data authority to his
own user profile and *ADD data authority to profile USERA.
The new object is set up like the old object. Now we must delete the old
object. USERB requires *DELETE data authority to USERA and *OBJEXIST
authority to the source object (more than required for a usual MOV).
These issues could generate an error message CPFA0B1, but this does not contain
the object name so it may be difficult to immediately determine if it is
referring to the source or target object. It could be the source or target
object or any of up to four user profiles.
The FTP command requires special considerations:
Individual authorities set on the parent directory (such as QPGMR and QSYSOPR)
will not be propagated to any new objects. Primary group profiles will be
propagated, however, so a primary group can be added to the command which
includes QPGMR and QSYSOPR.
Other options to add individual authorities include:
1 Setting authority using the FTP session options (for example, QUOTE RCMD
GRTAUT <parameters>).
2 Using an FTP user exit program to grant the authorities required when FTP is
used. For an FTP exit program example, refer to Rochester Support Center
knowledgebase document 16055109, FTP Exit Program: Server Example. To link to
document 16055109 immediately, click here (Document link: Database 'Rochester
Support Line KnowledgeBase', View 'All Documents', Document 'FTP Exit Program:
Server Example').
The EDTF command requires special considerations:
When using the EDTF command to create new files the authority for the new file
will have *RW regardless of parent directory authority. The authority for the
parent directory is not inherited.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
