Unconfigured Ad Widget

**Guest.Visitor** · 02-20-2001, 01:17 PM

RVKOBJ/GRTOBJ *exclude with *allobj

Robert, This has been discussed many times, but yes. You can limit the access to objects by using the GRTOBJAUT and modifying the object to EXCLUDE, etc. for a user. Even if that user has *ALLOBJ authority. The way I understand it is: The system first tests and object to see if the user has specific rights granted/revoked. If no specific rights are determined, then it checks the user to see if *ALLOBJ is specified on the profile. If you use the SEARCH facility, and look for *ALLOBJ, you will probably find several threads on this subject. -bret

**Guest.Visitor** · 02-20-2001, 01:22 PM

RVKOBJ/GRTOBJ *exclude with *allobj

Actually, it was my perusing of the other articles concerning this topic that spawned my question. In my circumstance, I am trying to use RVKOBJ/GRTOBJ with a user that has *allobj, and am having no luck whatsoever in getting the object secured. I also forgot to mention in my first post, that there are no auth lists for this object, which is a menu. Even though I use the *exclude parameter, the menu is still totally accessible to the user. Any suggestions, anyone? TIA Cliff

**Guest.Visitor** · 02-20-2001, 01:25 PM

RVKOBJ/GRTOBJ *exclude with *allobj

It is not possible to prevent a user with *ALLOBJ special authority from accessing any object becasue *ALLOBJ takes precedence over public and private object authority. You better let at least one user, the security officer, have *ALLOBJ authority or no one will have authority to grant *ALLOBJ when you need it. Some operations require the user to have *ALLOBJ special authority. Ed Fishel

**Guest.Visitor** · 02-20-2001, 01:53 PM

RVKOBJ/GRTOBJ *exclude with *allobj

I don't know Ed.

I'm in pretty good company with this one. **************** Previous post ****************** Submitted by Category Public David Abramowitz on 05/16/97 at 03:04 AM Security *ALLOBJ authority On Thursday, May 15, 1997, 09:39 AM, Boris Mezhibovskiy wrote: We are currently running under V3R1. Some of our users have ALLOBJ authority. Is there any way to secure individual objects from users with ALLOBJ authority? We would appreciate any help! Use the EDTOBJAUT command, for individual objects. Once done, it makes no difference whether or not users have *ALLOBJ authority. David Abramowitz ************* End of Previous post ************ Ed, There are 10 security values you can set per object. Each of these are checked prior to the *ALLOBJ authority on the user profile. -bret

**Guest.Visitor** · 02-20-2001, 01:55 PM

RVKOBJ/GRTOBJ *exclude with *allobj

Try the QsyRegisterFunction() to register critical functions (e.g. a menu call) in an application, and then use QsyCheckUserFunctionUsage() to limit users with SPCAUT(*ALLOBJ) from certain functions in the application. Ops Nav has a cool screen that can sign up users to registered functions.

**Guest.Visitor** · 02-20-2001, 02:05 PM

RVKOBJ/GRTOBJ *exclude with *allobj

Thanks Gene! Another way to circumnavigate the system with respect to *ALLOBJ, authority. Next we'll have Cartman complaining that the "/400 just does not respect my Ahh-Thor-Ahh-Tie!"

-bret

**Guest.Visitor** · 02-20-2001, 02:10 PM

RVKOBJ/GRTOBJ *exclude with *allobj

Bret, Take a look at the documentation of *ALLOBJ in the Security Reference manual. The text at http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3ALC04/4.3.12.1 says: All-object (*ALLOBJ) special authority allows the user to access any resource on the system whether or not private authority exists for the user. Even if the user has *EXCLUDE authority to an object, *ALLOBJ special authority still allows the user to access the object. Risks: *ALLOBJ special authority gives the user extensive authority over all resources on the system. The user can view, change, or delete any object. The user can also grant to other users the authority to use objects. A user with *ALLOBJ authority cannot directly perform operations that require another special authority. For example, *ALLOBJ special authority does not allow a user to create another user profile, because creating user profiles requires *SECADM special authority. However, a user with *ALLOBJ special authority can submit a batch job to run using a profile that has the needed special authority. Giving *ALLOBJ special authority essentially gives a user access to all functions on the system. Ed Fishel

**Guest.Visitor** · 02-20-2001, 07:03 PM

RVKOBJ/GRTOBJ *exclude with *allobj

There are 10 security values you can set per object. Each of these are checked prior to the *ALLOBJ authority on the user profile. -bret Bret, That's simply not the case. In general, OS/400 checks object security like this: a. User, b. Group, c. Public, d. Adopted And within each profile, for *ALLOBJ, Owner, Specific authority, Auth List. So, a user with the special *ALLOBJ authority gets access to the object on the very first check. Chris

**J.Pluta** · 02-20-2001, 08:17 PM

RVKOBJ/GRTOBJ *exclude with *allobj

I did a simple test. I created a user profile ALLOBJ, and granted it *ALLOBJ (don't worry, it's since been deleted ). I then signed on as a different user profile, created a library called HIDELIB, and the revoked all authority to that library for all users. I created a dummy profile DUMMY, and verified that he was not authorized to HIDELIB. I even went so far as to specifically revoke the authority to HIDELIB from ALLOBJ: GRTOBJAUT OBJ(HIDELIB) OBJTYPE(*LIB) USER(ALLOBJ) AUT(*EXCLUDE) Well, ALLOBJ could still see HIDELIB, even though nobody else (except the owner) could. So then I decided to flip *ALLOBJ on and off and see what happened. It was pretty clear: *ALLOBJ on - see the library *ALLOBJ off - don't see the library Interesting side point: when the user profile had *ALLOBJ, I DID have to grant it specific authority to the device description in order for it to log on. Kind of an interesting dichotomy there... Joe

**nycsusan@hotmail.com** · 02-21-2001, 04:50 AM

RVKOBJ/GRTOBJ *exclude with *allobj

So, a user with the special *ALLOBJ authority gets access to the object on the very first check What about if you specifically *EXCLUDE the user with allobj auth from the object? What happens then? Is s/he authorized to the object or not?

**Guest.Visitor** · 02-21-2001, 05:15 AM

RVKOBJ/GRTOBJ *exclude with *allobj

Joe, The fact that the *ALLOBJ user profile has to have specific authority to the device description is controlled by the QLMTSECOFR (limit security officer device access) system value. As the help text says: "This system value controls whether users with *ALLOBJ or *SERVICE special authorities need explicit authority to specific work stations." Ed Fishel

**Guest.Visitor** · 02-21-2001, 05:16 AM

RVKOBJ/GRTOBJ *exclude with *allobj

Susan, What about if you specifically *EXCLUDE the user with allobj auth from the object? What happens then? Is s/he authorized to the object or not? Again, authority checking is this order: User, Group, *Public, Adoption And within each "profile" above, the system checks for: *ALLOBJ, OWNER, Specific Authority, Auth List. I just remember "UGPA AllOw SpeciALs". If the user has *ALLOBJ, access is granted and OS/400 will never see that specific authority. Once OS/400 finds an authority, whether it is sufficient authority or not (well, group authorities are cumulative), the checking stops there. Chris

**nycsusan@hotmail.com** · 02-21-2001, 05:46 AM

RVKOBJ/GRTOBJ *exclude with *allobj

So there is no way to exclude a user with *ALLOBJ authority???? That's not cool.

**cwscholbe@dstsystems.com** · 02-21-2001, 06:17 AM

RVKOBJ/GRTOBJ *exclude with *allobj

Of course it's cool. That's the way it was designed. If you don't want a User to have access to objects, remove *ALLOBJ from their usrprf and work with security on the object level or auth lists or... Chris

Unconfigured Ad Widget

Announcement

RVKOBJ/GRTOBJ exclude with allobj

RVKOBJ/GRTOBJ exclude with allobj

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment