Unexpected results from Check_Authority BIF - making use of the GUSR setting
|Date:||6 March 2008|
|Product/Release:||Visual LANSA V11|
|Abstract:||In Version 11 the Group User setting is now used as a supplementary method of determining authority on VL, and this may affect existing applications|
|Submitted By:||LANSA Technical Support|
In Version 11 there have been some changes in the way that authorities are checked in VL. These changes have brought the PC side (Visual LANSA) closer in line with the iSeries security model. One change which might affect user applications is that the Group Profile is now used as a supplementary method of determining authority on VL.
The Group User setting is used on iSeries to centralise object authority administration for several users in one place. Assigning a group user to a user profile can give that user extended authorities to some objects, however in VL this was not being recognised.
In Version 11, LANSA now honors the Group User setting via the GUSR X_RUN parameter. However this may inadvertently give users access to files/fields which they previously did not have access to. To understand how this might affect your application, an explanation is necessary on how the Group Profile is determined on VL.
How does Group user affect authority checking?
This mainly affects SuperServer applications accessing an iSeries server. Checking authority for particular objects on the server is usually done with the Check_Authority BIF.
If your group user is set to the system owner (see System Maintenance on Tools menu) or Partition Security Officer (see Partition in repository browser), then you will have permission to access all files/fields/functions that they are set for no public access, even if the user profile you are using is NOT a System Owner/Partition Security Officer
This will be most noticeable when executing the application from a development environment, since the group user will most likely come from the user that was used to sign into the development environment. In a lot of cases this will be a partition security officer or a user of similar authority. Even when changing the USER session value in the application, the GUSR will remain as a security officer, giving incorrect access.
How does Group User get set on a Windows environment?
Firstly, when executing a form / process / function, the GUSR setting is read from the X_LANSA.PRO/x_run parameters. Then...
If a local database is used for the repository....
After connecting, the USER checked against the local database. If found, the GUSR setting is taken from the local database.
If a local database is not used for the repository...
(e.g. if the Exec XXXX to RDMLX iSeries icon is used or if the PSXX parameters are used to create the connection)
There is no lookup, and GUSR setting will be used as is.
If the form / process / function is a deployed application that does not have a local database
There is no lookup, and GUSR setting will be used as is (even if it is blank).
As you can see, changing the GUSR setting in the X_RUN parameters may not be a fool-proof method of specifying a particular GUSR.
What is the best method of specifying a particular GUSR for my applications?
The correct option is to change the GUSR setting in your code. This can be done by calling the Set_Session_Value BIF when changing the USER setting in preparation for a SuperServer connection, or as part of the initialization of your program. Note that *NONE is a valid setting for the Group User, and this ensures that authority is based on the User Profile only.