topic Re: SE38 Authorization in Application Development and Automation Discussions

SE38 Authorization

venkateswaran_k — Mon, 12 Sep 2022 06:25:16 GMT

Dear All

Kindly help me on this doubt

We are planning to remove SE38 access to all the users in production.

However, many of our Programs using SUBMIT statments inside the custom z-programs.

Hence, removing SE38 access - do they have impact on these SUBMIT statements being executed or interrupted.

Kindly help

regards,Venkat

Re: SE38 Authorization

FredericGirod — Mon, 12 Sep 2022 06:42:28 GMT

There is no link between SE38 transaction and SUBMIT statement.

SE38 must be removed from production system (and SE37, SE24, SE80, ....)

Re: SE38 Authorization

jmodaal — Mon, 12 Sep 2022 07:02:42 GMT

Hello,

I don't fully agree to your last statement. For end users: yes. But I think for the IT support the access to these transactions IMHO should be given, otherwise you make their work more difficult. If you want to avoid people executing any program, you can do this by removing S_DEVELOP with Activity 16.

Kind regards,

Jan

Re: SE38 Authorization

Colleen — Mon, 12 Sep 2022 07:30:57 GMT

program execution access if not via transaction code should be SA38 with S_PROGNAM/S_PROGRAM which then has the SUBMIT, BTCSUBMIT, etc. Transaction SE38 for code uses the S_DEVELOP

I find the backdoor - admins take away SE38 but leave SA38 with S_PROGRAM wide open 🙂

Re: SE38 Authorization

FredericGirod — Mon, 12 Sep 2022 07:37:01 GMT

jmodaal you have to chose between security and confort.

A production system should not be used by IT, there is no good reason to run SE38 transaction.

There is the solution of the Firefighter (in GRC) to give quickly a temporary role with a lot of authorization. You could recreate it with specific development in your system.

Re: SE38 Authorization

Sandra_Rossi — Mon, 12 Sep 2022 07:41:39 GMT

To be precise about what you say "removing SE38 access", I guess you mean "removing authorization with object = S_TCODE and TCD = SE38".

SUBMIT does not check this authorization as you can see in the ABAP doc, and you can check by doing an authorization trace. ABAP doc SUBMIT: "When the statement SUBMIT is executed, an authorization check for the authorization group specified in the program attributes is performed using the authorization object S_PROGRAM. The program attribute Start Using Variant is ignored in SUBMIT." (you can deduce that there is no other authorization check)

Re: SE38 Authorization

matt — Mon, 12 Sep 2022 07:49:23 GMT

Sometimes it's a choice between security and having a functioning system. But yes - FF and other (better) solutions are available for these scenarios.

And then they took FF access away from IT in production...

Re: SE38 Authorization

jmodaal — Mon, 12 Sep 2022 07:54:24 GMT

Hello frdric.girod,

I see your point, however, I think it is a little bit theoretical and does not fit for everyone. Not every customer uses FireFighter.

I know of big SAP customers having the IT support staff on their productive systems with dedicated, restricted roles. FireFighter is also in use, but for emergency situations only. But of course the scenario you mentioned is also present.

With S_DEVELOP / Activity 03 (Display) only I do not see any reason why SE38 and similars are to be banned.

Kind regards

Jan

Re: SE38 Authorization

RaymondGiuseppi — Mon, 12 Sep 2022 07:54:38 GMT

The submit statement

Doesn't require to be allowed to SE38 or SA38 (S_TCODE)
The only authorization check performed checks the authorization group specified in the program attributes, it is performed using the authorization object S_PROGRAM. There is no check if the program isn't assigned to an authorization group.