Re: Security to use RDP's debugger when you do not have *SERVICE

On 25 Apr 2012 04:46, rob@xxxxxxxxx wrote:

I was recently talking to some people who didn't know (since they had
that authority) that others often can't use the RDP debugger because
it uses STRSRVJOB under the covers and they do not have *SERVICE
authority. I am wondering if my knowledge is an ancient tidbit.
Because I am seeing ptf cover letters for V5R3 that says that was
true but they came out with a ptf that allowed you to not have to use
the circumvention of giving *SERVICE authority to those programmers
who wanted to debug. And that ptf is now on a cume.
http://www-912.ibm.com/a_dir/as4ptf.nsf/a18db68aae4a7d81862566ba005d145c/8a01f72308e5954d8625733f005d90a2?OpenDocument&Highlight=2,debug,service,authority

The referenced PTF corrected a defect whereby a function that should have worked for a user with the proper authorities was incorrectly being denied. The change did not remove a requirement for the user of STRSRVJOB to have SPCAUT(*SERVICE). The STRSRVJOB had not required *SERVICE special authority before nor after the PTF; use of the command required then and still, that the user invoking the command must have at least *USE authority to the user profile of the job to be serviced.

So, do they have matching ptf's for supported OS's or is it now in
the base?

The change would be in the base of future releases; looks like since v5r4 for that APAR SE29540

I see there may still be a limitation on trying to debug a job
running under a different user profile this way. You need some access
to the user profile as outlined in
http://www-912.ibm.com/a_dir/as4ptf.nsf/a18db68aae4a7d81862566ba005d145c/2af1b7b575d3f2c486257380006e3405?OpenDocument&Highlight=2,debug,service,authority

That is just a nuance to the above. Presumably the code, perhaps even the code change in the PTF for the aforementioned APAR, was apparently verifying user authority by looking for the exact authority mask of one of the special values *USE, *CHANGE, or *ALL, rather than verifying the mask for each of the three separate authority values *OBJOPR, *READ, and *EXECUTE [which define the special value *USE].

We tend to not give *ALLOBJ authority to our development staff.
Increases security and cuts back on those "works for me, sucks to be
you" responses to the end users. Not that they would put it like
that but it's just a way to summarize.

I presume the issue is not the "job servicing" but with the actual "debug". For security\integrity purposes a user doing debug must have a specific level of authority to the program(s) they will debug. While they *could* obtain any necessary authority from the SPCAUT(*ALLOBJ), that is frowned upon.

Refer authority requirement for the STRDBG and ADDPGM commands. The command help text suggesting "You must have either *CHANGE authority to the program, or *USE authority to the program and *SERVICE special authority." is probably an [if not "the"] issue for those that do not have *ALLOBJ.

Regards, Chuck