How risky of S_PROGRAM and S_DEVELOP

[Former Member]

Dear Experts,

I got EWA report said we have many users have authorization to start all reports and I checked there are many roles with authorization object S_PROGRAM and S_DEVELOP with P_GROUP = "*"

However most of them don't have authorization of SE38/SA38

I want to know how risky of S_DEVELOP and S_PROGRAM, without SA38/SE38 how can they start report.

And where do S_PROGRAM and S_DEVELOP come from and how they works without SA38/SE38

Thanks

Fuyi

[Former Member]

S_DEVELOP auth object without being properly restricted in Production even without SE38/SA38 can be dangerous.

S_DEVELOP even with 03 activity and DEBUG obj type can give you a debug access of a code. Having this in the Production is not a good idea....we had audit recommendation because of which we removed object type DEBUG and PROG from this object even when the activity was 03.

S_DEVELOP with activity 01 and 02 and Object type DEBUG can give you editable access in SE16N.

Try this in your sandbox and you will see ....execute SE16N -> any table like USR02 -> in the command line type in &sap_edit -> it will activate SAP editing function -> now you can edit the table from SE16N....try it without using &sap_edit and it will not give you editable access

We need to careful with this object.

To be very honest S_PROGRAM has not given me much problem with the ABAP programs having their Authorization group maintained....maybe few other people can chip and tell us if we have any critical issues with this Authorization object

[Former Member]

Hi,

Just curious, because I'm currently doing an audit around this...

If the authorizations granted in production is:

S_DEVELOP

Activity: 03

Object Type: *

Is my understanding correct that with this access while the user can open the debugger by typing in "/h" in the command line, he won't be able to save any changes he made since he doesn't have activity 02. In this case, will it be okay to for the users to have this access in production?

[Former Member]

The most immediate hassle you will notice is performance degradation because the debugger hogs dialog work processes.

An advanced hassle is external debugging where the caller has control over ALL input parameters they have access to and the session context user might have much more than that...

See threads in this forum about "SAP_ALL minus a little bit and a few tcodes..." ...

S_PROGRAM is a dog's breakfast from a conceptual perspective. It is only a very blunt tool for some "absolute" module dependent access and has little uses beyond that in the system (eg. org. level values, or activities).

S_DEVELOP is always venom in all forms, but the concept has improved here in the past years because you can distinguish between display and execution in the local system where the user is logged onto.

Via RFC and the split-screen editors you do not have a realistic chance to prevent execution of code if many users use the connection for this and various other purposes...

The check is only "hardcoded" in display-mode. That will however not help you much to find stronger calls once the user can display the code and navigate into the others (and find where they are excecuted from, or execute them from other object types) ...

--> A semi-skilled person will easily hose your security with such access.

Rather give them an emergency user procedure for a user which cannot logon at all, and that on a temporary basis and control and log access to that!

Less meetings as well...

Cheers,

Julius

Edited by: Julius Bussche on Aug 16, 2010 11:32 PM

[Former Member]

Which release are you on?

Concentrate on S_DEVELOP first, particularly the activity field and the object type field. It is the central object for protecting the development workbench (which is written in it's own program language...) and is very powerfull.

There is no valid reason why anyone would need any authority for this object, except display for some object types assigned to an administrator and possibly temporary exceptions for a technical auditor as well.

Cheers,

Julius