Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Performance Issues with Debugging even in Display Mode

Former Member
0 Kudos

Hi not certain if this would sit in Security, ABAP or Basis, but lets start here as it is security related.

S_DEVELOP with any activity on DEBUG on a production system is a concern, but what are the performance related issues when a super user has to go into debug in display only on a production system because of a really complex issue?

I've heard in the past of a scenario where system performance was impacted, and we have notes around the allocation of S_DEVELOP display DEBUG access to this point. (I've summarised these below)

The risk with debug is associated with the length of time that the actual debugging process is being performed.

u2022 Work processes are dedicated solely to the users for the duration of the debug. If these are being performed for a long time, these can cause issues with not enough work processes being available.

u2022 It can cause DB2 locks. If the debug session last awhile, DB2 locks are not released. This impacts the availability of tablespaces, thus, affecting various transactions running across the system.

Even with these concerns, security will often get asked for debug display access.

As security is about risk identification, assessment and then controlled access what do other organisations do?

Options (not exhaustive) are "No Debug ever" or "Debug display only via a fire fight or super user on a time limited basis".

We are currently in the "debug display only via fire fight" camp, but would like to canvas opinion on this.

As one of the concepts of security is Availability of data (and to an extent ensuring the systems are up and running) do the performance risks push the security function to the "No Debug Ever" stance.

2 REPLIES 2

jurjen_heeck
Active Contributor
0 Kudos

From a security standpoint debugging is mainly dangerous because lots of programs will read extensive sets of data before the authority-check statements define which parts will be processed and/or presented to the user. This raw data can be made visible when debugging. Debugging with changed parameters will allow to bypass almost any authority-check.

I've never taken performance issues into account when advising not to allow debugging in production. If it needs to be done, preferably via a fire-fighter user.

Former Member
0 Kudos

If you need to debug in production, then 9 times out of 10 you need to do root-cause analysis: The developer is the problem.

Writing sloppy code and not testing properly should not be an excuse for debugging in production.

But of course, there are exceptions even when you do try to keep them to a minimum.

To add to Jurjen's comments, also note that the debugger only has a limited capability of doing a rollback. So you can quite easily and unintentionally create inconsistencies in the system - also in display mode - which is an integrity problem, and typically more critical than availability problems or even potential confidentiality concerns.

Cheers,

Julius

Edited by: Julius Bussche on May 15, 2009 10:50 AM