The other day I received an e-mail from a customer, which was concerned about the fact, that we in InterForm400 has some programs, that are adopting the authority from the QSECOFR user profile. I did answer them in full and I think, that they are happy with the answer, but I would like here to underline, why we are adopting the authority.

What does ‘adopt authority’ mean? Normally a program on the System i will get the authority of the user running the current job. This means e.g. the program is not allowed to do anything, that the user is not authorized to do.  So the few of the programs in InterForm400, that are adopting the authority of QSECOFR, are actually given the same authority as the QSECOFR user profile.

Why is it necessary with this higher level of authority? As a service InterForm400 is always making sure, that the user profile owning any merged spooled file is the same who owns the original spooled file. This means e.g. that the WRKSPLF command will show the merged spooled files, it is possible to see who generated the merged spooled files (even though they are generated in batch via Auto Forms Control), and you can protect the spooled files from being read by others if needed. This would not be possible without the QSECOFR authority.

What have InterForm400 done to eliminate the risks of a security leak?

1. InterForm400 will not call a user program unless the user program is owned by QSECOFR. This makes sure, that only users with very high authority is allowed to generate programs called by InterForm400.
2. The programs, that are adopting the authority of QSECOFR does not give any access to a command line, so the authority cannot be misused.
3. The command lines that can be found in InterForm400 does inherent the Limit capabilities (LMTCPB) parameter from the specific user profile. So if you are normally not allowed to enter a command, then you are also not allowed to do that on InterForm400 command lines.
4. The shipped user profiles of InterForm400 are delivered with very limited authority as programs adopt authority whenever needed.

What would be the alternative? If the same functionality should be possible without adopting the authority, then the customer would need to add extra authority to all users generating spooled files that are to be merged. Giving extra authority to users could potentially be risky if the end users would access the System i via PTF, ODBCS, iSeries Navigator etc