02-13-2013 10:20 AM
We do not allow direct table changes in our productive environment, so we have isolated the program RKSE16N_EDIT in its own Program Authorization Group.
Only a few FireFighter ID’s have authorization to SA38, but not to this special Program Authorization Group to avoid they can switch on the feature &SAP_EDIT.
Unfortunately I have now seen in table SE16N_CD_KEY that some users recently have made direct table changes so I would like to know if &SAP_EDIT currently is turned on or off in the system.
I tried looking at the selection screen of program RKSE16N_EDIT, but I can’t figure out if the feature is on or off.
Anyone who knows how to see this ?
02-13-2013 10:27 AM
02-13-2013 11:27 AM
The feature &SAP_EDIT were removed some years ago by the note you are referring to.
Later the feature were re-introduced and the program RKSE16N_EDIT are used to switch on and off the feature, but I don’t know how to see if it's on or off.
02-13-2013 11:38 AM
If you are authorized to run the program, then you can turn it on and off for yourself. Whether it is on or off for you is in a table.
*....the current setting has to be read additionally
*....first get highest position
select max( pos ) from se16n_edit into (ld_pos).
if sy-subrc = 0.
*.......now get the corresponding entry
select single se16n_sap_edit from se16n_edit
into ld_sap_edit
where pos = ld_pos.
02-13-2013 12:36 PM
Thanks, Julius
I just checked table SE16N_EDIT on the productive system and it's empty, so I don't know if the feature is on or off.
I better get the program execute once to ensure the feature is deactivated.
Best regards,
Peter
02-13-2013 1:05 PM
Looking at the underlying code of SE16N, an empty SE16N_EDIT is also treated as "&sapedit not allowed".
However, "normal" changes via SE16N (without using the &sapedit hack) also appear in SE16N_CD_KEY, so maybe have a closer look at those tables, e.g. their SE11 and SOBJ settings, or overall client settings, that might have allowed changes directly in production.
Thomas
02-13-2013 2:20 PM
Then no one ever turned it on there before. That also means that either:
a) Thomas Zloch is correct and the tables are in fact maintainable.
b) The CD entries are from before the patch went in.
c) The buggers are using the function modules on the inside of SE16N directly and not respecting this switch. Go to SE37 and do a where-used-list on FM SE16N_INTERFACE or check in the audit log to see who is single-testing it.
I tip on (c) being the explanation and raise Thomas 2 points that I am right.. 🙂
Cheers,
Julius
02-13-2013 3:28 PM
02-13-2013 4:37 PM
Ok... SE16N_EDIT is client dependent and the report does inserts on it's table without using the standard DB table logging of maintenance views (no surprises there... 🙂
But SE16N_INTERFACE has client independent and also CLIENT SPECIFIED capabilities and imports the client from the caller.
So... I raise you a further 2 Nockherberg Maibocks and place my bets on someone turning it on and off and editing from a different client!
Cheers 😉
Julius
02-14-2013 9:53 AM
Well, I sure won't bet my house against your Security expertise, but I can risk two more beers, I guess
I hope we will learn about the outcome from OP.
Cheers
Thomas