*PUBLIC authority on new object

[Guest.Visitor]

I thought that the *LIBCRTAUT on the library determined the *PUBLIC authority of a new object. I have a library where the *LIBCRTAUT is *ALL (just for a test) but when an end user creates a new file with CRTDUPOBJ, the *PUBLIC authority is USER DEFN, not *ALL. The *LIBCRTAUT is not defined as *SYSVAL (QCRTAUT which is *CHANGE). I'm not trying to accomplish a specific programming task here but rather understand how this works. And, when a user creates an object, the owner of the object depends only on the value of OWNER specified in the user profile which can be *USRPRF or *GRPPRF, right?. So, if *USRPRF is specified for profile JOHNDOE and JOHNDOE is the job user will all new objects be owned by JOHNDOE? (unless CHGOBJOWN is used). Thanks. Chris

[Guest.Visitor]

Chris, <blockquote><tt>>I thought that the *LIBCRTAUT on the library determined the *PUBLIC authority of a new object. I have a library where the *LIBCRTAUT is *ALL (just for a test) but when an end user creates a new file with CRTDUPOBJ, the *PUBLIC authority is USER DEFN, not *ALL. The *LIBCRTAUT is not defined as *SYSVAL (QCRTAUT which is *CHANGE). << </tt></blockquote> CRTDUPOBJ is the only "Create" command that doesn't use the Default Create Authority on the library (*LIBCRTAUT), and there is a good reason. CRTDUPOBJ assumes that you want to create an _exact_ duplicate of an object, including it's current public and private authorities. So when you do a CRTDUPOBJ, the new object will have exactly the same authorities as the old object. It is for this reason that the user must have *OBJMGT authority to do a CRTDUPOBJ. OS/400 security rules specify that you must have *OBJMGT authoritiy to an object in order to read or manipulate authority to that object. <blockquote><tt>>And, when a user creates an object, the owner of the object depends only on the value of OWNER specified in the user profile which can be *USRPRF or *GRPPRF, right?. << </tt></blockquote> Right. <blockquote><tt>>So, if *USRPRF is specified for profile JOHNDOE and JOHNDOE is the job user will all new objects be owned by JOHNDOE? (unless CHGOBJOWN is used). << </tt></blockquote> Darn near right. The only difference being that when a new object is created, ownership is assigned to the jobs "current user"... which is not necessarily the same person as the "job user". But 98% of the time, "current user" and "job User" are one and the same. hth, jte

[Guest.Visitor]

<font color=blue>So, if *USRPRF is specified for profile JOHNDOE and JOHNDOE is the job user will all new objects be owned by JOHNDOE? (unless CHGOBJOWN is used).</font> <font color=dark green>Darn near right. The only difference being that when a new object is created, ownership is assigned to the jobs "current user"... which is not necessarily the same person as the "job user". But 98% of the time, "current user" and "job User" are one and the same.</font> John, Are you referring to API's that temporarily switch the current user? Or are you referring to adopted authority or something else here? Your comments are much appreciated. Chris

[Guest.Visitor]

<blockquote><tt>>Are you referring to API's that temporarily switch the current user? Or are you referring to adopted authority or something else here?<< </tt></blockquote> I'm referring to the swap profile API's. When you use them, the "job name" (128789/JOHNDOE/QPADEV0003) stays the same, but the "current user" is whoever you swapped to. jte

[Guest.Visitor]

Chris, The file create issue: Is the file a physical or logical? Sometimes logicals will not allow *all authority. Scott

[Guest.Visitor]

This was a Physical file, not a logical file. John Earl gave me the answer I needed: CRTDUPOBJ even duplicates public authorites. Thanks. Chris

[David Abramowitz]

You can never have *ALL authority on a LF, because there is no data in the object, and therefore no data rights. Dave

[Guest.Visitor]

David, Data rights to a LF are controlled by the data rights on the PF. So, if you have *ALL authority to the PF, you can certainly have *ALL rights on the LF. The LF should contain a subset of the PF data authorities. Chris

[David Abramowitz]

If you take a look at the detail of object authority of an LF. you will see some authorities are missing. They can neither be granted nor denied. That is what I meant by *ALL. I also understand what you are saying, and indeed you are also correct. Dave