Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

NO_ATIME?

Posted Jun 25, 2004 22:13 UTC (Fri) by Ross (subscriber, #4065)
Parent article: Kernel release status

I'd like to hear a little more about this. Can any use use this flag? If
so does it only work when reading files by that user? If no there are some
security implications because access times can no longer be trusted.

(Yes, they can't be trusted now when the user can edit the inode time info
but that isn't the case for system files.)

(Log in to post comments)

NO_ATIME?

Posted Jul 1, 2004 12:31 UTC (Thu) by Peter (guest, #1127) [Link]

(Yes, they can't be trusted now when the user can edit the inode time info but that isn't the case for system files.)

I can't think of a lot of reasons why hiding that you have accessed a file really is security-sensitive. Arbitrarily changing the atime or mtime, yes, that's something you don't want people doing to files they don't have permissions to - but merely not updating the atime - that seems rather less serious. It's not like the atime gives you a real audit trail, after all - it doesn't say who last read a file.

NO_ATIME?

Posted Jul 1, 2004 13:35 UTC (Thu) by cesarb (subscriber, #6266) [Link]

From the glibc manual:

int O_NOATIME Macro
If this bit is set, read will not update the access time of the file.
See File Times. This is used by programs that do backups, so that
backing a file up does not count as reading it. Only the owner of the
file or the superuser may use this bit.

So, only the owner of the file or the superuser can use this flag.

http://lkml.org/lkml/2004/6/11/192 has the patch and discussion.