Page 1 of 1

Using SURROGAT class to enable use of su command in USS

PostPosted: Thu Jun 12, 2014 4:41 pm
by Blackthorn
I'm trying to su to a different user in USS. The manual says that you should use the -s flag to turn off password prompting, and as long as you have read access to the BPX.SRV.user profile in the SURROGAT class this should work. It doesn't though. Is there anything else that needs to be set anywhere?

I have run this command -

READY
RDEFINE SURROGAT BPX.SRV.OPS0047 UACC(NONE)
RACLISTED PROFILES FOR SURROGAT WILL NOT REFLECT THE ADDITION(S) UNTIL A SETROPT
READY
PERMIT BPX.SRV.OPS0047 CLASS(SURROGAT) ID(OPS0052) ACCESS(READ)
RACLISTED PROFILES FOR SURROGAT WILL NOT REFLECT THE UPDATE(S) UNTIL A SETROPTS
READY
SETROPTS RACLIST(SURROGAT) REFRESH
READY
END

but I'm still getting this -

OPS0052@PROD:/u/ops0052>$su -s ops0047
FSUM5027 su: User is not a surrogate of "ops0047".

Any ideas?

Thanks.

Re: Using SURROGAT class to enable use of su command in USS

PostPosted: Thu Jun 12, 2014 5:04 pm
by enrico-sorichetti
did You logoff/logon ???

Re: Using SURROGAT class to enable use of su command in USS

PostPosted: Thu Jun 12, 2014 5:14 pm
by Blackthorn
Hi Enrico,

I was initially connecting via ssh from another Unix server and I had disconnected and signed back in.

I have now tried logging out of TSO and back on and tried it in omvs, but I am still getting the same issue.

Thanks.

Re: Using SURROGAT class to enable use of su command in USS

PostPosted: Thu Jun 12, 2014 5:32 pm
by enrico-sorichetti
unfortunately I cannot be of more help ...
it works for me

IBMUSER:/u/ibmuser: >su -s enrico
FSUM5027 su: User is not a surrogate of "enrico".

after the commands
=> permit bpx.srv.enrico class(surrogat) id(ibmuser) access(read)
=> setr raclist(surrogat) refresh

IBMUSER:/u/ibmuser: >su -s enrico
IBMUSER:/u/ibmuser: >id
uid=1(ENRICO) gid=0(SYS1)
IBMUSER:/u/ibmuser: >


yess, the logoff/logon sequence is pretty murky
the above sequence went fine without logoff/logon

logoff/logon is usually to test with a clean environment

Re: Using SURROGAT class to enable use of su command in USS

PostPosted: Thu Jun 12, 2014 5:51 pm
by Blackthorn
Enrico, you're a star! I'm used to using su on AIX where the command prompt and home directory both change as soon as you switch user's -

root@p25n10e0:/ # su - ops0052     
ops0052@p25n10e0:/home/ops0052 $   


I hadn't realised that this was not the case in USS. Using the ID command confirms that I have in fact switched -

OPS0052@PROD:/u/ops0052>£id           
uid=1098(OPS0052) gid=11(OPSGROUP)     
OPS0052@PROD:/u/ops0052>£su -s ops0047
OPS0052@PROD:/u/ops0052>£id           
uid=1067(OPS0047) gid=11(OPSGROUP)     
OPS0052@PROD:/u/ops0052>£             


Previously the error was only occuring after I had issued the command the second time, i.e.; I had switched users and did not have authority to switch again from there. I should have twigged that the first command, whilst apparently not doing anything, was in fact working as expected.

Thanks ever so much for your help.

Re: Using SURROGAT class to enable use of su command in USS

PostPosted: Thu Jun 12, 2014 6:42 pm
by steve-myers
I presume SU is equivalent to SUBMIT, though from a USS file.

The intent of the RACF SURROGAT class is to permit user A to submit a job to run using user B's userid without specifying user B's password in the JOB statement.

For it to work,
  • The SURROGAT class must be enabled
  • An appropriate SURROGAT profile must be defined by a security administrator -

    RDEFINE SURROGAT B.SUBMIT UACC(NONE) OWNER(B)

    The OWNER allows user B to enter PERMIT commands for the resource.
  • User B (or the security administrator) enters a PERMIT command to allow user A to submit a job using user B's userid.

    PERMIT B.SUBMIT ACCESS(READ) ID(A) CLASS(SURROGAT)

See the chapter "Allowing Surrogate Job Submission" in Security Server RACF Security Administrator's Guide for your z/OS release.

Re: Using SURROGAT class to enable use of su command in USS

PostPosted: Thu Jun 12, 2014 7:19 pm
by enrico-sorichetti
nope :D

in UNIXese
su -- Change the user ID associated with a session


with a wild guess for switch user