I thought that all I'd ever use the Linux Audit system for would be security. More recently, I also chose it to find out where some file corruptions came from.

1 Who Did What?

For some of the services we run at CERN, whether it's the interactive login service or the batch computing service, it is useful at times to be able to determine who runs what where and when. The Linux Audit is a very easy-to-use tool for doing this. It logs into /var/log/audit/audit.log events such as logins but also command execution.

I remember a discussion we once had with the HTCondor project head who said that it was more constructive to audit your users rather than corner them into a privilege system. This was an inspiring thought, underlining the importance of auditing.

2 File Corruption

More recently, I had to debug an odd problem whereby compiled Python system files such as /usr/lib/python*/socket.pyc lose all their attributes. In other words, if you run:

>>> import socket
>>> dir(socket)
['__builtins__', '__doc__', '__file__', '__name__', '__package__']

... you can contemplate that the module can still be imported but there isn't the useful attributes the socket module would normally provide you with. It's a problem that some people have reported but I haven't been able to find any explanation so far. This phenomenon happens once in a blue moon, but often enough in a large-scale cluster to become annoying. The first question that sprang to mind was, what does it? I called the Linux Audit to the rescue. The auditctl command lets you insert a watch on a file for operations of your choosing such as reads, executes, writes and attribute changes. I did so for the two latter operations to try and understand my problem:

# auditctl -w socket.pyc -p wa

You can subsequently run the ausearch command to print any event corresponding with the operations you chose:

# ausearch -f socket.pyc

Not unlike what's logged into /var/log/audit/audit.log, this command will print out crucial information such as the time, working directory, process ID, user ID and command involved in the operation.

Now, this Python compiled file corruption is sufficiently rare that I've not been able yet to catch any event. But it's good to know there is a watch in place that will catch the culprit when it strikes again. And we'll then perhaps have an answer to this corruption mystery.

3 References

• Linux Audit
• What causes a .pyc to become “empty”?