Disable changing variables during debug for a specific program

[Former Member]

Hi,

We've a program that we need to run ONLY IN DEVELOPMENT system (it will not be moved to QA or Prod). As all developers will have debug access, we some how want to restrict all users from changing the variable values (example - changing sy-subrc from 4 to 0) in debug. Developers should be able to debug and change variables for all other programs.

I know all variable changes during debug will be written to system log and can be retrieved from SM21. But if there is a possibility we want to restrict while changing itself.

Is it possible to achieve this using security setup?

Is it possible to achieve this using code? Can we do something like throwing an error if someone is trying to debug this program?

Thanks

Ram

[Colleen]

Hi Ram

Have you read up on the documentation for the S_DEVELOP authorisation object?

Regards

Colleen

[mvoros]

Hi,

you can't disable change in debugger for subset of programs. In this case you have all or nothing. So unless you remove change in debugger from all users then you can't achieve this with authorization. Even if you could do that, a user with access to change in debugger can assign temporary role to itself that gives him authorization. A person with access to change in debugger is unstoppable.

I believe that there is no way how to achieve this in code. From simple reason if you were able to somehow prevent execution of this program in code then I as a developer I would make a copy of this program and remove those parts that prevent me to debug it. There also used to be a trick to wrap critical part in macro but that can be bypassed as well.

Cheers

[Former Member]

What if they don't have ACTVT '01' for the debugger and only '02' for their own packages?

Then they must write and F8 a new program which edits the protected one, so it can be caught in the ABAP Editor exit.

Force them to make noise and use alerts on the syslog to make noise...  🙂

If developers read code and comments which tells them to bugger off then they don't voluntarily go looking for trouble IMO.

Or we can dig deeper than ACTVT '01' to make noise....

Noise for (bad) developers is better than prevention.

Cheers,

Julius

[Former Member]

If it is an isolated program in development systems only, then you can legitimately hard code a few things as that is your exact requirement.

Use Macros to DEFINE a sy-sysid check and use statement STOP in the marco. Add a few global variables to the code in the macro as well and comments as warnings...  🙂

That should do the trick. SAP does the same.

Else...

If sy-debug ='X' then STOP anyway.

However you must prevent the developers from using the system debugger and GOTO statement function to skip over the macro.

If you cannot control that, then you also cannot control them from changing the program either.

In that case you must restrict their authorizations to object names or isolate the coding to a package which blocks the debugger.

Hard call! You cannot realistically restrict someone who can insert code into a running program or system.

Cheers,

Julius

[Colleen]

If sy-debug ='X' then STOP anyway.

It's development and they are developers then communication/warning - do not debug this is required

But taking your idea a nice message of "Did you miss the memo? You better have a good reason when I hunt you down"

But even then, there is nothing stopping the developer from copying the code to a new program name and claim they are "prototyping"

[Former Member]

There are ways of controlling permitted calling programs and you can go a long way protecting that against unsuspecting developers, but I think we need to understand here why this program should not be able to be debugged in a development system.

What is really the goal which Ram is trying to achieve here? Protect some secret algorithm from being displayed? Prevent the program from executing? Prevent the program from being changed? Protect the program completely against the ABAP editor tools?

It might even be best to take this code out of the ABAP environment and rather start it as an external program - like SAP does with C-functions or TCP/IP destinations.

Cheers,

Julius