On Tue, 17 Jul 2001, richard offer wrote: > The rationale for using the fd in the audit record rather than the pathname > or any arbitary number is that fd is the object handle that is being acted > on. read() is not acting on a pathname, it acts on a fd. But the fd is a non-global (per-process) and ephemeral value (it is both non-persistent and can even refer to different files at different times during the lifetime of a process). So what good does it do in an audit record? Better to audit information that might possibly be useful in reconstructing what happened, like the pathname and inode number. You want to know what object's data was read, not what fd was used. > Once the open has succedded the file can be unlinked, what then should one > report as the object that is being read ? A new file may have been created > with the same pathname in the meantime. So reporting the pathname is > incorrect, its a different object that just happens to have the same value > in one particular namespace. You can also report the device and inode number, which will continue to identify the file object distinctly until the deleted file is completely released. SELinux audits all three: pathname, device and inode number. But again, how is reporting the fd useful in an audit log - what useful additional information can I reconstruct at a later point in time? Ultimately, you are merely mapping that fd back to a pathname or inode number anyway when presenting the audit data to a person. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Jul 18 2001 - 06:14:27 PDT