S_C_FUNCT — Authorization for OS-Level C Function Calls

S_C_FUNCT guards the ability of an ABAP session to call named C-language kernel functions rather than ABAP function modules. One of the functions in this category is the routine that actually shells out to the operating system, which is why the object surfaces whenever someone tries to run an external command defined in SM69 or fired through a background job step, a spool device exit, or a program that still uses low-level system calls. The structural fact that causes most confusion: this check happens one layer below the familiar business authorization check. A user can pass every field check on S_LOG_COM and still be stopped, because the kernel refuses to make the call at all before S_LOG_COM is reached. Most systems never notice this object exists, because default profiles and copied SAP roles carry a wildcard for it. It only becomes visible after a role has been rebuilt from scratch or stripped down for hardening.

The object carries a single technical field rather than the multi-field structure typical of business authorization objects.

The check fires from deep inside the kernel, ahead of the ABAP-level function module that finally hands the string to the operating system. It is triggered before an external command defined and released in SM69 actually runs, whether that command was launched directly from SM49, from a background job step that calls an external program, from a spool or print formatting exit that shells out for post-processing, or from any custom program still using older low-level system call constructs. Because the check happens before S_LOG_COM is evaluated, a user missing S_C_FUNCT never gets far enough for the command-name and host restrictions on S_LOG_COM to matter at all. This is also why the failure can appear in places that have nothing obviously to do with SM69 in the transaction name, such as a report that quietly calls out to compress a file or convert a format using an OS utility.

Start with SU53 immediately after the failure, but treat it as a first hint rather than proof: because the check sits inside kernel code rather than the standard ABAP AUTHORITY-CHECK statement, SU53 sometimes shows a generic denial against S_C_FUNCT with little context, or misses the check entirely if the session state has already moved on. If SU53 is inconclusive, run the authorisation trace for the affected user, execute the failing action once while the trace is active, then filter the trace by object name to isolate the exact CFUNCNAME value being checked and the point in the call stack where it was denied. Hand the security team the user ID, the CFUNCNAME value from the trace, the transaction or program that triggered it, and separately the exact external command name expected to run under SM69, since that second piece is needed for S_LOG_COM and gets requested in the same round trip.

This is a security team fix, not a functional configuration fix, since the object is almost never maintained explicitly in custom roles and is usually restored by copying it from a delivered profile rather than authorised field by field. A good request states the user, the CFUNCNAME value from the trace, and the business scenario, since security will typically add it alongside the matching S_LOG_COM entry rather than in isolation.

The most common trap is fixing S_LOG_COM and declaring the ticket closed, because that object is the one visible in SM69 documentation and the one everyone remembers to check, while S_C_FUNCT sits silently underneath and keeps blocking the call. A role can look complete against every documented external-command authorization object and still fail, because S_C_FUNCT was never carried over when the role was built from a template that predates the command being added. People also conclude that the SM69 command definition itself is broken, restart testing from scratch, retest the same command entry repeatedly, and never look at authorizations at all, because the error message the end user sees is often generic and does not name the object.