As Lustre Changelogs are a centralized mechanism reporting activity on the file system, we would like to use it as a basis for an audit facility for Lustre. The aim is to be able to track all accesses to files residing on Lustre, so that they can be recorded and looked up later for auditing purposes.
Changelogs cannot be used as-is to achieve auditing, because of the following limitations we have identified so far:
(a) uid/gid information is not recorded;
(b) OPEN and GEXATTR operations are not recorded;
(c) CLOSE operations are not recorded if the file is opened in READ_ONLY mode;
(d) Changelogs only record successful operations, not attempts.
Further comments on limitations:
LU-1996 (https://review.whamcloud.com/4060) added support for jobid in Changelogs. If jobid is set to procname_uid, Changelogs will contain procname.uid information. So this could be used to know which user is doing the access. But jobid can be used for another purpose than audit, so we cannot always rely on it. We should create a new changelog extension similar to changelog_ext_jobid, that would hold uid/gid information.
(b) and (c) We do understand that it would have a performance cost to record OPEN and GEXATTR operations, as it would mean generating a write in the Changelogs for a read operation. Similarly for a CLOSE when a file is opened read-only. We will have to exclude OPEN and GETXATTR from the default Changelogs mask, and potentially create a dedicated changelogs entry type for the 'close on read-only' case, excluded by default. Moreover, we will evaluate the performance cost when these operations are recorded.
(d) Having all access attempts recorded will definitely increase MDS/MDT load, so we should examine carefully the performance impact of doing this. We would warn users about how much they would suffer by recording all access attempts.
I will feed this ticket by pushing patches to address the various limitations identified here (and possibly others to come).