suggest enabling Auditing is a better option as this will record all the information you need.

You can try this in your test server to get an idea how this works and how you can then review the logs.

There is several options. I suggest you check this on a test server 1st.

Yes you don’t have to convert the system to ‘trusted’ mode.

Here I give you an example how you can enable auditing and audit ‘root’ user.

Setup the auditing logfiles.
# audsys -n -N 2 -c /var/.audit/auditing -s 1000
created audit trail directory: /var/.audit/auditing
auditing system started
Verify the above command:
# audsys
auditing system is currently on
current trail: /var/.audit/auditing
next trail: none
statistics- afs Kb used Kb avail % fs Kb used Kb avail %
current trail: 1000 90 91 8912896 7740272 13
next trail: none
Auditing system is actively writing to 2 file(s).
Next select a user for which end-user desires to track and create an audit trail of failed logins. For example, please select the root user.
secweb a terminal-based gui method can be run or use the command-line to achieve this.
# secweb
Using secweb here's the 1st screen shot:
Auditing and Security Attributes Configuration
--------------------------------------------------------------------------------
s - System Defaults - Configure system-wide values of security attributes
l - Local Users - Configure per-user values of security attributes of local users
e - Audit Events - Set audit state for events
c - Audit System Calls - Set audit state for system calls
d - View Audit Parmeters - View current audit monitor and log parameters
v - View Audit Log - Filter and view contents of audit log
Select l to go to the next screen which would display among other users, the root user as well:
Auditing and Security Attributes Configuration-> Local Users
--------------------------------------------------------------------------------
Displaying Local Users
Name User Id User Values
======================================================================================================================================================
...
root 0 no <-- notice the value of "no"
...
--------------------------------------------------------------------------------
x-Exit smh ESC-Back 1-Help /-Search
ENTER-View Security Attributes m-Audit multiple users 2-userdb(4) Manpage
Hit m to Audit multiple users .
Scroll the cursor to the root user and select it by hitting the space bar, and hit a Audit selected users .
The next screen will also show the command-line equivalent of achieving the above.
Click ok and determine confirm success of the operation with this message:
Command Successful
press Enter Key to continue
The next screen should now show up root as being setup to be audited:
Auditing and Security Attributes Configuration-> Local Users ->Audit multiple users
--------------------------------------------------------------------------------
Displaying Local Users
Name User Id User Values
======================================================================================================================================================
> root 0 yes <-- notice the value of "yes"
The command line equivalent for the above.
#/usr/sbin/userdbset -u root AUDIT_FLAG=1
To confirm that the root user has been setup for auditing:
# userdbget -u root
root AUDIT_FLAG=1

Now use secweb again to select the Audit Events (e) first to select the events and then go to Audit System calls (c) and select appropriate system calls you would like to audit.
#secweb
Auditing and Security Attributes Configuration
--------------------------------------------------------------------------------
s - System Defaults - Configure system-wide values of security attributes
l - Local Users - Configure per-user values of security attributes of local users
e - Audit Events - Set audit state for events
c - Audit System Calls - Set audit state for system calls
d - View Audit Parmeters - View current audit monitor and log parameters
v - View Audit Log - Filter and view contents of audit log
Select e to go to the next screen which would display events that could be audited
Use m to audit multiple events and scroll and select all the events using spacebar


x-Exit smh s-Audit Success Only b-Audit Both Success and Failure ESC-Back /-Search
SPACE-Toggle Selection f-Audit Failure Only n-Audit Neither Success nor Failure 1-Help

Then you can choose any of the options that are given above to enable to disable event/syscall.

EXAMPLE:

In my case I enabled the event ‘delete’ and the audit syscall ‘rmdir’ to check if root deletes any directory.
Then I created a directory called test and removed it using rmdir.

To view the logfiles created by the auditing subsystem:
#audisp -u root

E.g: #audisp -u root -c rmdir /var/.audit/auditing > /tmp/rmdir.out
# more /tmp/rmdir.out
Event: rmdir
Time: Fri Dec 10 15:29:48 10 IST
PID: 292
PPID: 26742
User/Grp: 0/3(root/sys)
Groups: 3(sys), 0(root), 1(other), 2(bin), 4(adm), 5(daemon), 6(mail), 7(lp), 20(users)
Effective privileges: "BASIC"
Permitted privileges: "BASIC"
Retained privileges: "BASIC"
Audit tag: 0: -1:root:201012100857
TTY: pts/1
Return1: 0
Arg 1 (file info):
given path = "/test"
inode = 594
device = 64, 0x3
mode = 040755
owner uid/gid = 0/3
type = directory

Similarly you can audit many events/syscall which you can view via secweb.
This gives all the details you are looing for.


More details refer the man page of ‘audsys’ ‘audisp’ etc
Also check the admin guide.