Date: Wed, 11 Jan 2006 17:34:58 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: joe <freebsd-security@FreeBSD.org> Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org, dds@FreeBSD.org Subject: Re: bin/91622: /bin/cp does not update atime of the source file Message-ID: <20060111171411.O73013@delplex.bde.org> In-Reply-To: <200601110309.k0B39SQ8006489@www.freebsd.org> References: <200601110309.k0B39SQ8006489@www.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Jan 2006, joe wrote: >> Environment: > RELENG_4 20051028 >> Description: > [cp fails to update atime] > > this occurs regardless of whether or not the user has > rwx permissions on the source file. does not apply of > course if the source filesystem is mounted read-only. > they are read-write here. > > since the source file is indeed being read, the atime should be updated. This is because cp(1) doesn't actually read(2) the file. It mmap(2)'s the file and reads memory. POSIX doesn't seem to require that cp sets atimes or otherwise acts as if it reads the file. Similar for cmp(1) and other utilities that use mmap() to read files (install(1) is another). The problem is mostly fixed in -current by "setting" (not actually setting, but marking for update) atimes in mmap(). I think to be strictly correct, setting of atimes should be nearer to munmap(2) than mmap(). No read has occurred from userland's viewpoint at mmap() time. However, since the OS can't tell if applications read mmapped memory unless their is a pagefault, the atime would have to be set on every pagefault to be as correct as possible, and I think mmap() prefaults some pages so it would have to set the atime whether or not the application reads the pages. So I think setting atimes in mmap() is required in practice. This leaves the problem that later pagefaults never set the atime, so the atime set by mmap() becomes out of date. I think the atime should be set by mmap() of there is at least one later pagefault. Setting it for every pagefault may be too inefficient. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060111171411.O73013>