-
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
-
Re: How risky of S_PROGRAM and S_DEVELOP
Ross Dorado 2010-8-16 下午10:41 （回复 Nishant Sourabh）
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?
-
Re: How risky of S_PROGRAM and S_DEVELOP
Julius von dem Bussche 2010-8-16 下午11:34 （回复 Ross Dorado）
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
-
-
-
Re: How risky of S_PROGRAM and S_DEVELOP
Julius von dem Bussche 2009-2-18 上午9:58 （回复 Fu Yi Chen）
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