Cannot login with SAS SPAWNER PRODUCT

Document ID : KB000050044
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

Having an user connection problem after the upgrade from TSS r14.0 to TSS r15.0 (product SAS SPAWNER).

With TSS R14, we got the message:

BPXP015I HFS PROGRAM /bin/login IS NOT MARKED PROGRAM CONTROLLED

But the connection was OK (the program is NOT marked controlled)

With TSS R15, additionally to the above message we got:

BPXP014I ENVIRONMENT MUST BE CONTROLED FOR DAEMON (BPX.DAEMON) PROCESSING .

The connection is refused (spawn forbidden)

The stc acid got PERMIT ACCESS(ALL) on IBMFAC(BPX.DAEMON)

Solution:

No PROGRAM permissions will make any difference here, as the concept of a Program Controlled environment in the RACF sense has no equivalent in TSS.

But the concept of Program Control in the USS sense does exist, and that is where the problem lies.

It is possible to have too much access in the USS world. In particular, if the started task acid has access to IBMFAC(BPX.DAEMON) every UNIX program

executed must be marked as program-controlled.

There are essentially two ways to fix the problem:

  1. If the acid really is intended to be used as a daemon, all programs executed must be marked program-controlled.

  2. If it is not intended to be used as a daemon, it needs to not have access to IBMFAC(BPX.DAEMON)

Since the program causing a problem here is /bin/login, and that is not normally a program that needs to be marked program-controlled, the solution here is likely to be that the acid must not have access to the resource:

TSS REM(stcacid) NORESCHK
TSS PER(stcacid) IBMFAC(BPX.DAEMON) ACCESS(NONE)

Note that removing NORESCHK may have consequences beyond denying access to the BPX.DAEMON resource, but it will be necessary.

The other question is why this works differently between R14 and R15.

While TSS code has little to do with all of this, we do have one program that is responsible for keeping track of the messages and issuing them under the right circumstances. In addition, the return codes from this program tell USS whether or not there is a problem.

Under R14, the program is detecting an error and issuing the BPXP015I message, but is setting the return codes incorrectly so that USS does not know that there is a problem. The USS code then allows the connection to continue and fails to issue the BPXP014I message.

This is due to a bug in our program.

Under R15, the bug no longer exists and the processing is correct. Both messages are issued, and since there is a problem the processing ends.

So R15 is behaving correctly, while R14 has a bug. The R14 bug is actually corrected by RO26496, so after applying that fix R14 will behave the same as R15.