Linux / sapuxuserchk / sapcpe

[schuess]

Hi

I'm wondering how you deal with sapuxuserchk and/or why SAP does not cope with the below problem:

* When we installed SAP Systems / SAP Kernel patches manually in the past we executed saproot.sh, which sets sticky bit and permissions for the file sapuxuserchk in ASCS and DVEBMGS kernel folders

* If we now do updates/kernel patches via SUM oder elselike I more often realise these sapuxuserchk executables are never overwritten, because normally this takes care via sapcpe which cannot overwrite these files due to root-ownership

Currently, we deployed newest kernels via SUM SPS maintenance; files sapuxuserchk however, are still dated 2014 🙂

Of course, I can do this manually; with >100 SAPSIDs this kind of a time consuming task.

How do you cope with that?

Why does SAP not make sure a new copy of sapuxuserchk is written to DIR_EXE if I execute saproot.sh or cope with that problem during SUM runs or the like?

Do I still need to execute saproot.sh / set sticky-bits and ownership in current kernel at all? Because all I can find in official SAP notes refers to old 720-kernels

Curious regards

Michael

[isaias_freitas]

Hello Michael,

The sapuxuserchk is still used / might still be required, depending on your servers' / landscape configuration.

Thus, I would say that it still recommended to updated it and set the appropriate permissions (suid bit, owned by "root:sapsys").

One test you could do is to remove the suid bit and change the ownership of the file to "SIDadm:sapsys". Then, logon with a user that is not SIDadm and execute:

/path/to/sapcontrol -nr XX -queryuser -function AccessCheck Stop

- "XX" is the instance number

- With the "queryuser" argument, sapcontrol will ask for a user/password interactively. Provide the SIDadm credentials.

If the sapcontrol command works while sapuxuserchk does not have suid and is owned by root:sapsys, then the auxiliary tool sapuxuserchk would not be required at your environment.

If it fails, set the suid again and change the ownership back to root:sapsys. Repeat the test and it should be successful this time.

Regards,

Isaías