this week, a colleague pointed me to the possibility to hook your own code into SAP GUI downloads via a user-exit. Since downloads are always a big security - and data protection topic, I took a closer look.
Generic download authorization: S_GUI
When downloading data to the frontend, the authorization object S_GUI is checked (with ACTVT 61). This is a very unspecific check, as it does not take the affected data into account – if you have appropriate authorizations, you can download roles, the SFLIGHT table or your colleagues' salary. It's just a client-wide "switch", which either allows or disallows downloads. Many authorization admins don't pay much attention to S_GUI, but rather focus on data access authorization objects. Anyway this is not sufficient, as downloaded data may be passed to third-parties easily or analyzed inappropriately.
SAP offers 2 user-exits to extend download authorization checks:
- SGRPDL00 — User-exit for "normal" SAP GUI downloads
- HRPC0001 — User-exit for HR-specific downloads; logical databases: PNP (HR master data) and PAP (recruitment data)
The first one is called by the GUI_DOWNLOAD function module – i.e. for each and every frontend download, while the second one is HCM-specific. To get started, I decided to inspect SGRPDL00, as this one has the best coverage.
User-exit SGRPDL00: Creation
First of all, we need to create an add-on project via tcode CMOD to implement the user-exit.
Enter the project name "SGRPDL00", click on "Create", enter the project attributes and then go for "Enhancement assignments". When you're prompted to save, say "Yes" (← hard decision) and choose a package ("Local object" is fine, if you're just playing around).
After that, enter "SGRPDL00" as the enhancement name, click on "Components" and double click on the function exit name:
Since you don't want to modify the SAP standard function module, double click on the include ZXFILU01. SAP tries to baffle you with a warning message:
… nice try, but just press Enter and you'll be prompted, whether you'd like to create the include. After ticking "Yes", you can start to implement the code, which will be called during every frontend download.
User-exit SGRPDL00: Implementation
The function module EXIT_SAPLGRAP_001, in which our code runs, provides 2 input parameters:
- IS_LIST_DOWNLOAD — whether the user is downloading a list (Standard list or ALV)
- NO_AUTH_CHECK — whether the GUI_DOWNLOAD function module was asked to not check S_GUI
and allows throwing the exception "NO_AUTHORITY" – which means that the download is forbidden.
Paste this code to get you started, activate it and don't forget to activate the user-exit itself.
The above code is a documented example… you'll for sure want to add your own code there; anyway it demonstrates a bunch of possibilities. One of the most interesting aspects is that it creates an Application Log entry for every download. Although the Security Audit Log provides similar functionality, it's possible to add additional information – the table name for SE16 in the above example code.
Unfortunately, you don't have access to all variables from the calling program… which makes it a bit difficult to add useful information (have a look at how the include gets the table name for SE16). If anybody has a better idea, please tell me.
The user-exit HRPC0001 is specific to HR/HCM and works a bit different. The implementation in include ZXP04U02 does not perform any check itself, but is rather expected to return a report and form name. This form is responsible for the check and may be located within the calling report's context – thus enabling your code to access any global variable therein. This way you can take the HCM-specific context into account to determine whether the download is okay or not.
When copying data to the clipboard, S_GUI is not triggered – SAP Note 997201 provides a solution at the cost of a modification.
- Uploads are not covered.
- Non-GUI downloads are not covered (BEx, Portal, …)
- If you mainly need reliable logging for each and every client, you might want to check the SAP UI Logging solution.
If you ever wondered, where SAP stores your report source code, you probably came across table REPOSRC – but the source code is stored in a compressed format, so there's no way to get hold of it directly.
I've been trying to figure out, how this compression works for some time now… fortunately, several people dealt with the SAP DIAG protocol recently – which got me off the ground.
The DIAG protocol uses a form of the Lempel-Ziv (LZ) compression algorithm and a bold attempt confirmed that this is also true for the source code compression.
The code stored in REPOSRC-DATA is actually compressed using the LZH algorithm (Lempel-Ziv plus Huffman coding), which is used by the
SAP DB MaxDB database too (thanks to Dennis Yurichev for the idea).
Knowing this, I wrote a decompression tool around a small portion of the MaxDB code, which also takes care of some SAP specialties:
- The 1st byte of the compressed data seems to be junk (or might have a special meaning !?)
- The first 2 bytes of the decompressed source are junk, too ?!
- Lines are terminated with character code 0xFF, which has to be adjusted
- The 1st, 3rd, 5th … decompressed byte contains NUL (not sure, why !)
The decompressed source code has a fixed line length of 255 characters (blank-padded).
- Download this archive (it contains the decompressor tool compiled for Win32 and an ABAP report to dump the binary source code). The source code is available here; you can easily compile it on Linux/BSD/Unix/Windows using the enclosed build script.
- To extract the compressed source code from SAP, use the report "ZS_REPOSRC_DOWNLOAD". It reads the DATA field from table REPOSRC for a given report and stores it in a binary file on your workstation.
- Decompress the file on the command line.
PS: Works for Kernel 7.x, no guarantee for older releases.
PS 2: The functionality on non-Unicode systems is unknown… I'll check this later.
Have a nice day!
using personal users to execute batch job steps is not a good idea!
Of course it's convenient, but those users might vanish or their authorizations might change – but how to clean this mess up? Since SE37 does not allow you to select jobs by step user, one might try to use SE16 (→ table TBTCP) to find the affected jobs… which will drive you crazy, believe me!
This time, I'll provide you with another nice report to clean up your system and prevent any batch-related headache!
- Create a new report in SE38 and paste this source code (don't forget to set a program authorization group).
- In the selection texts:
- Tick "dictionary reference" for R_JOBNAM, R_SDLUSR and R_USRNAM
- Leave all other texts empty ("?...")
- Activate & execute.
On the selection screen you can choose the:
- job name, -scheduler and -status (like in SE37) and
- step user name (initially set to your user name, but try DDIC or SAP*).
Submit your selection and you'll get a result similar to this:
The columns at your disposal are:
- Job name — … self-explanatory.
- Job no. — the internal ID of the job.
- Scheduler — the user, who scheduled the job.
- Job status — … self-explanatory.
- Step no. — the step ID that matches your selection (the job might consist of more steps).
- Rept. name — the report or command.
- Name — the step user (green, if the user still exists; red otherwise)
As always in my reports, you can double-click on almost everything:
- Job name — goto SE37 and show all matching jobs by name.
- Job no. — show only the particular job in SE37.
- Scheduler — open SU01 for the user, who scheduled the job.
- Step no. — display the step list of the selected job.
- Rept. name — jump to SE38.
- Name — show the step user in SU01.
Red is dead, green is clean … unless it's a personal user ! 😎
another common finding of audits is, that not all (of your customer-) tables are assigned to a table authorization group — allowing everyone with S_TABU_DIS and DICBERCLS = "&NC&" to access them. Therefore, you might want to take care of this…
(Certainly, this is not always a sensible check 🙄 – it depends on the data contained in the respective tables! … but anyway many auditors check for it.)
The assignment of tables to authorization groups is defined in table TDDAT; but it only contains registered assignments. If a developer never assigned his/her table to an authorization group, it won't appear in it. So the problem is to find all tables without an entry in TDDAT plus all tables with an empty entry there. Furthermore, some "tables" are uninteresting, e.g. structures, help views and temporary or local tables, as they don't contain any sensible data.
Please, do not start Excel at this point… there is a better way!
Obviously we need a way to list all unprotected tables (no matter whether they're in TDDAT or not) and automatically exclude all table- (and view-) types containing uncritical or no data.
Therefore, we need to find DDIC objects, which…
- have no entry in TDDAT or
- are assigned to the authorization group "&NC&" (which has the same effect as no entry) or
- are assigned to an empty authorization group (same effect) and
- aren't internal tables or append structures (as they cannot contain data) and
- aren't help views, structure views or append views (which do not contain real data as well) and
- aren't tables for temporary data and
- aren't local (i.e. not transportable) ← YMMV.
Fortunately, I was bored some time ago and programmed a report for this…
- Create a new program in SE38:
- Fill in the attributes:
… and choose a suitable authorization group (P_GROUP, marked red)!
- Copy and paste the source code.
- Maintain the selection texts:
… and leave P_COUNT and P_EMPTY empty, tick "Dictionary reference" for the other ones.
- Activate and execute it.
The report shows the following selection screen on execution:
On the first tab you can:
- Select the range of Table names to inspect, e.g. "Z*".
- Choose whether or not to Check tables for data (i.e. determine whether the number of rows is > 0)
… which might heavily increase the runtime!
- Decide whether to Show empty tables (if you've selected the previous option).
The second tab is pre-filled with sensible values (YMMV):
- The Authorization group field is set to "&NC&" and empty values (only for tables that exist in TDDAT).
- The Table category is set to exclude structures and append structures.
- The View type field excludes help-, structure- and append-views as well as views without any type,
- The Delivery class option excludes tables for temporary data.
- The Package field is dynamically ❗ filled with all local packages on the system, the report runs on.
Now execute it and you'll get a result like this:
In the ALV header, you can see the number of tables matching your selection and the number without an authorization group.
- Table name — … self-explanatory.
- Short description — table description from the data dictionary.
- AuGr — assigned authorization group (usually "&NC&" or empty).
- Description — the authorization group's description from TBRGT.
- Data — whether or not the table contains any data (only available if you ticked "Check table for data").
If it contains a flash symbol, the check failed.
- Cl.-spec. — whether or not the table is client specific.
- Log — whether or not the table has "Log data changes" enabled in its technical settings.
- Del. class — the delivery class, which might give you an indication to classify the table contents.
- Package — the package the table belongs to (might point you to the "area" the table belongs to).
- Tab. cat. — the type of the table (e.g. transparent -, cluster -, pool table or view).
Furthermore, you can double-click on the following fields:
- Table name — jump to SE11.
- Short description — inspect the selected table via SE16.
- AuGr — open SE54.
- Data — show the number of entries in the table.
- Cl.-spec. — show description.
- Log — show technical table settings.
- Del. class — show all available delivery classes.
- Package — open the package explorer.
- Tab. cat. — show a list of table types.
Have fun, play around with the options and clean up your system! 😀