On Jun 27, 2017, at 01:18, Matthew Sanderson <matthew.sander...@anu.edu.au> wrote: > > Hi all, > > Change logs would form a more complete audit trail if they contained a user > ID (and possibly also a primary group ID, maybe even all of the user's > supplementary group IDs). > > Is there a particular reason why this information isn't currently stored in > changelog records? > > After some investigation with my colleague (cc'd), it looks like this would > be a comparatively easy change to make. The information is already sent over > the wire to the MDS; it's just not persisted in the changelog. > > The additional fields could be added to the userspace 'struct changelog_rec' > as an additional extension, similar to the way renames and job IDs are > stored. As far as I can tell, this wouldn't break compatibility with existing > applications that consume changelogs.
This definitely sounds interesting. Originally, the ChangeLog was developed for tracking resync of changes to the filesystem, and the ownership of the files can be found by looking up the inode by FID. Definitely there has been some interest in having auditing for Lustre. Your analysis of the updated ChangeLog format is correct - it was implemented to allow addition of new fields, and I'd definitely be in support of your proposal to record the process UID/GID accessing the files, if auditing was enabled. Would the client NID also need to be recorded? I was thinking that enabling auditing for Lustre would potentially be too much overhead, but if this was limited to a single record for each UID/GID opening each file it would likely be fairly reasonable since only a single record would be needed for even a large MPI job. Cheers, Andreas -- Andreas Dilger Lustre Principal Architect Intel Corporation _______________________________________________ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
