RE: Debug anomaly

Ed,

Hopefully this doesn't confuse the issue more. I realize
authority is checked at runtime, but I always thought it
was derived when you sign on or swapped a profile. I
am under this impression because changes to a profile
are not retroactive to jobs that are signed on.

I am changing the effective group to get more authority
before running strdbg. I thought that I should get the same
authority as I would get by changing the group profile
and then signing on. That is not the case with debug.

The strdbg command works OK if I change the profile
to add the group profile in question and then signon. It
does not work if I change the profile and then set the
effective group for the job. Swaps do not work either,
but my explanation of how I have tested that would
probably add to the confusion.

On our system no one has authority to anything except
their profile, outq, message queue, etc. We impose this
on all users for our system. There are just too many
interfaces to the system to lock down so we start with
no authority to anything. That way if we have a hole in
one of those interfaces (ftp, odbc, telnet, smtp, ???) we
are not exposing much. I am looking into how I could
implement this for programmers and system
administrators.

This debug thing is minor and it has a workaround
so it is not a big issue.

David Morris

>>> edfishel@us.ibm.com 03/18/02 07:25AM >>>

David,

>                         I do have all of the
>rights to the program, source, and library that the
>manual says are required via my effective group.
>I really just want to understand what is happening.
>Effective groups and swaps are not very well
>documented, but 99.9% of the time they work the
>same as a base profile/group/supplemental group.
>
>The really weird thing to me is that changing the
>group of the executing job allows debug. I don't
>think I have ever seen a case where authority is
>derived from the profile at run time. It is always to
>the last swap or signon. I have not changed any
>authority whatsoever and I can make it work by
>changing the group. That is the second anomaly.
>On the other hand, I could have simply missed
>that passage in the manual.

Up until now I have been confused by this discussion. Perhaps I still
am.
The reason to change the effective group profile of the job is to get
more
or less authority. The only time authority is derived from a profile
or
group profile is at runtime. So if the effective group profile is
different
at the time you do DSPMODSRC than it is at STRDBG then what you are
seeing
may make perfect sense.

Ed Fishel,
edfishel@US.IBM.COM