Ken, Let's check the silly things first. Does the group profile have *ALLOBJ authority? This would explain the behaviour you're seeing. When the user has an entry in the authorisation list this will be checked before the group's special authority and he will get *USE rights. Without a user entry the group's special authority would be checked before the authorisation list authority. Dave...
Unconfigured Ad Widget
Collapse
Announcement
Collapse
No announcement yet.
Group vs Public in an AUTL
Collapse
X
-
Group vs Public in an AUTL
Hi Dave and Chris, The user has no special authorities. The programs are not adopting authority. I confirmed this by using UPDDTA under the users id (the scenario above is the same under UPDDTA). I'm in a Kazakhstan for a week now - any further help/suggestions would be greatly appreciated but it will be about 10 days before I reply. thanks again Ken
Comment
-
Group vs Public in an AUTL
Cuong, OS/400 stops checking when an authority is found and uses that authority (regardless of what that authority is). Group authority is checked for *PUBLIC, so the group should only have *USE in the scenario described in this thread. Chris
Comment
-
Group vs Public in an AUTL
Hi Susan, Good question. If more than one group profile is specified in the user profile, then when OS/400 checks for group authority, the combined authority of the user groups in used. So, if user JOHN has GROUP1, GROUP2, GROUP3 listed in his profile, OS/400 checks the authority for GROUP1, then the combined authorities of GROUP1 and GROUP2 and then the combined authorities of all three groups. Chris
Comment
-
Group vs Public in an AUTL
Chris: What I meant was: Unless *PUBLIC has *EXCLUDE authority, the OS/400 wouldn't bother to check for the *USE authority of AGRPPRF anymore. If he gave *USE for *PUBLIC and also *USE for AGRPPRF, it became meaningless. So in order to accomplish what he wanted to do (*USE authority for AGRPPRF), *PUBLIC should has either *EXCLUDE or *USE authority to that object, not more than that.
Comment
-
Group vs Public in an AUTL
I have a file secured with an authorisation list *PUBLIC *AUTL no other authorities other than the owner on the file. In the AUTL are the entries: AGRPPRF *USR PUBLIC *CHANGE However when a user belonging to group AGRRPRF wants to add/delete a recored to the file they are allowed to. This is where I am confused because the security refrence manual states that the in the 7 steps of authority checking that group authority is checked before public, specifically; step 6. Groups authority on the AUTL securing the object step 7. Public authority for the object or for the authorsation list So how come users belonging to AGRPPRF get to update. If I change the authority list to so that the user is specified as *USE rather than the group then the update is refused as expected. I must be missing something here - can anyone tell me what it is? thanks Ken
Comment
Comment