IBM i Global

Hi Miguel,

Security relies, at a minimum, on 3 components:
* system values, particularly QSECURITY
* profile rights, especially special rights
* and finally the rights defined on the object.
QSECURITY has an impact, notably if it is set to 20, because it grants the special *ALLOBJ right to user profiles.
If a user profile has the special *ALLOBJ right, they have the right to access all objects, including deleting and modifying data.
Finally, and this may be where your problem comes from, the object itself contains the users' access rights. If its public rights are set to *CHANGE, which unfortunately is often the default value, or *ALL, then all users can modify the data. You can check this with the DSPOBJAUT command (or EDTOBJAUT to modify). But be careful, modifications at this level have a global impact on access rights to the object, which can cause application malfunctions.

You can assign a private right to the object for the relevant profile (EDTOBJAUT), which will take priority over the public right. With the F6 key, you add the profile and give it the *USE right for read-only access.

Dominique

Miguel

Does that user profile has *ALLOBJ special authority or not?  Does the user belong to any group profile or not?  (Use DSPUSRPRF to check this.) 

IBM i has a fixed flow of checking for access authority to an object as shown below:

You can see from the flow above that private authority is checked BEFORE AUTL.  If there is a private authority entry for that user profile that explicitly allows or denies the access to the object, then the flow do not proceed onward to AUTL. I guess this may be the case for you. 

You should also be aware that there are 2 levels of access authority: at the object level and at the object's content (data) level as shown below (from DSPOBJAUT command):

You said you can delete the file, that is the object level authority which is separate from data authority. So, you need to check both levels.   But assigning the object authority value of *USE serves read-only purpose for both object and data levels. 

You said you need the user to be able to "invoke read-only commands". There is no mechanism for this purpose as it is redundant. Assigning proper object and data authority can serve the same purpose. Otherwise , you have to assign private authority for that user profile to all command objects in your system which is tedious. 

Can you post the DSPOBJAUT screen of, say, 2 or 3 objects for me to see here so I can provide more tangible analysis ?  (Keep pressing F11 to see both OBJECT level and DATA level as shown above)   You need to also let me know the user name at issue so I can check if there is any private authority of that user already assigned to the objects or not. If so, it explains why your AUTL does not work.   

Normally, try to use just private authority first to serve your purpose because using AUTL has negative performance impact when accessing a lot of data at the same time. 

In addition to the *ALLOBJ or Group Profile membership question....how is this person executing the delete of files ? Are they using a command line for it or calling a program? If calling a program, is that program running under adopted authority of the owner ? If so, that could be why its happening. Another option for you to consider...remove command line from that person and stick them in a custom menu of things they need /allowed to do. While this won't stop other types of access to the system - like running SQL statements from ACS or equivalent, this may prevent a bulk of what and how they are performing these tasks. 

>>>>  Another option for you to consider...remove command line from that person and stick them in a custom menu of things they need /allowed to do.  <<<<

As far as using 5250 session is concerned, there is no need to "remove command line from that person".  You just need to set the user profile's parameter Limited Capabilities to *YES and then  assign a proper menu name to that profile. This way, even though that user still sees a command line, that user will receive error messages when trying to run any commands that have their parameter ALWLMTUSR(*NO) and this parameter of most, if not all, commands is set to *NO by default already. 

Hello 
As you are using autl I will assume it span to all DB files the user needs to work with in that case you should remove any special authorities from the user and give him private authority in the AUTL as read only like *use / read X . 

More advanced suggesting would be  :

If it is for ODBC Connection you should use exist programs to control the user for example if the query starts with update do not allow it 

Or you give the user no special authority but you make a program that run with adopted authority *OWNER for example we call it readdta were you control the flow and the program run with adopted authority for the files that the user does not have authority to  

You can give a user for example *allobj (But carefully They might find a way around to open command line or use data transfer ) to give him read to all files but limit the user by removing command line and strict him to work through your menus and programs were you can control the flow from there for example you make an option called read db file or display OBJD 

Regards