Functional Usage Capabilities

Did you know that you can limit access to system functions by registering which users can access which functions? You can allow access or deny access via the functional usage capabilities; depending on the component, you could allow one user to change some settings and allow another user to only view those settings. Many system components support the use of function usage capabilities to provide more granular access to their capabilities. Functional usage does not eliminate or replace the need for securing resources on your system; it simply provides an additional way to control what functions a user can access.

There are:

• Three commands
  • Change Function Usage (CGGFCNUSG)
  • Display Function Usage (DSPFCNUSG)
  • Work with Function Usage (WRKFCNUSG)
• A set of APIs in the security category under User Function Registration Facility APIs
• A graphical user interface that allows you to manage the function usage on the system. The GUI for this capability is under Application Administration – Host Applications, within System i Navigator (where it is an optionally installable component) and Systems Director Navigator.

The User Function Registration Facility API set was first introduced into the system way back in V4R3, so this capability has existed for quite a while. The commands were introduced in V5R3, which improved ease of use since a program no longer had to be written to implement it.

The first use of limiting function access within the operating system was in the V4R5 release when the Trace Connection (TRCCNN) command was introduced. Service commands required *SERVICE special authority; but *SERVICE special authority is quite powerful, and it's very likely that you'll want to allow someone to collect a dump or a trace, but not want them to have *SERVICE special authority. Today, most all of the service commands (trace, dump, watch) are supported with customized access via functional usage.

Since the introduction of TRCCNN, more system components have added support for granular access via functional usage. You can see the full list of functions supported with the DSPFCNUSG or WRKFCNUSG commands by taking the default of *ALL. The GUI also provides a list of all functions that are available.

The GUI for this capability can be found under Application Administration; it is the Host Applications category that provides this support.

• Default Access allows all users to access the function by default 
• All Object Access allows all users with all object system privilege to access the function
• Customize allows you to add or remove users or groups in the Access Allowed and Access Denied lists.

The following screen capture shows the kind of information you can see with the Display Function Usage command. In my example, you can see that I have allowed user DAWNMAY to access trace functions, even though DAWNMAY may not have *SERVICE special authority. User DAWN is not allowed to access trace functions.

 

Comments

[Jeff Geldermann]

Where can I find detailed documentation that describes exactly what each of these FUNCTION IDs controls?
Does one of the available function IDs allow me to control interactive SQL usage. I have some users (new programmers, support people,etc. where I want to prohibit the DELETE, UPDATE, CREATE operations but allow a SELECT operation.

[Rob Berendt]

The options in WRKFCNUSG are also available in iNav. Right click on the system name and select Application Administration.

Alas, there are no capabilities to restrict types of SQL selections. However, if you don't allow your users to use STRSQL, but instead restrict them to STRQM you can
10. Work with Query Manager profiles
2=Change
Page down to bottom.
Select allowed SQL statements
There you have the control requested.
Caution: If your users get into STRSQL, or iNav's "Run SQL Scripts" or any number of tools outside of STRQM these restrictions do not apply.