Disable change authorization in debug mode for single class

[Former Member]

We wanted to disable some  "Generic Object Services" such as attachment list / create attachment. So certain users are not allowed to see the attachment. We achieved it using SGOS to Substitute standard service class with our own class. then use "CHECK_STATUS" method.

Now everything works fine. The set of users which are not supposed to see these attachments also involves developers. These users have access to debug mode and can change values at run time and change behavior of the class method.

So we remove authorization for changing variable values in debug mode. But this blank ban does not work as in certain cases they need to change values in debug mode.

Can some one advice if we can stop developers from changing values of variable in particular class method? or we need a redesign of our solution?

[Former Member]

ACTVT 02 (change variables) supports the object name and package, but ACTVT 01 (system debugging) does not as those programs override almost everything and the calling program does not matter anymore.

But... if your developers need to permanently have debugging access to production then that is a different problem and you probably have much bigger ones than unauthorized display to GOS objects.

If this has been going on for a long time, then you probably have a big can of worms there... (in the organizational and change management sense...)

Cheers,

Julius

[Former Member]

ps: Look to see who has object type FUGR with ACTVT 16 as well.

That is also the same as SAP_ALL actually as remote FMs don't check your authorizations and update FMs are not meant to check and auths.

In the same way, the debugger does not check application authorizations (such as changing account number or setting sy-subrc to 0 after failed checks.

In both cases you can control at the object name level, but you cannot effectively control at levels such as org. fields and document types etc.

--> Remove the dedugging from "normal" operational authorizations. Throw it over the fense into a controlled emergency use concept.

Cheers,

Julius

[Former Member]

Thanks Julius,

We are trying to achieve this in a test system not in production. In production we have controlled emergency use concept. There developers can have debug change authority only in case of emergency. But issue is that its a different team with different geographical location. They are allowed to have access to attachment services as well. We are not. When client is copied the attachments are also copied to test system .

Will explore more based on your suggestions.

thanks.

Mrugesh.        

[mvoros]

Hi,

they can also go straight to DB table using SE16 and get attachment from there. Right?

Honestly, that case when they really need to have access to change in debugger should be so rare that you can handle it as an exception. Whenever they need it they can submit a request and they will get it for limited time. As Julius said if they need it on daily basis then they are doing dodgy stuff.

The macros could not be debugged. So you could wrap your logic into macro and try to prevent easy change of sy-subrc with this technique. It seems that the new debugger allows macro debugging (I haven't tested it). So you can't try to use this trick anymore. Not that I would advice to use this trick.

I think every change of value in debugger gets logged in SM21 so I would have a look there how often it happens in production.

To summarize, a developer with allowed change in debugger is unstoppable.

Cheers