O_NOATIME and files in /proc

O_NOATIME and files in /proc

[Bernd Petrovitsch]

Hi all!

Is there a specific reason that open can not open files (at
least /proc/noatime and /proc/cpuinfo) under /proc with NO_ATIME as the
following program shows:
----  snip  ----
{12}cat noatime.c

#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>

int main(void)
{
	int fd = open("/proc/uptime", O_RDONLY|O_NOATIME);
	if (fd == -1) {
		printf("fd=%d, errno=%s\n", fd, strerror(errno));
	} else {
		printf("fd=%d\n", fd);
	}
	return 0;
}
----  snip  ----
When I compile and run it, it prints
----  snip  ----
{13}./noatime 
fd=-1, errno=Operation not permitted
----  snip  ----
Removing the "NO_ATIME" makes it work (of course).

I can also set the "noatime" mount flag on a remount and it shows up
in /proc/mounts but it makes for the above no difference.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: O_NOATIME and files in /proc

[Andrew Morton]

On Tue, 17 Nov 2009 18:06:29 +0100
Bernd Petrovitsch <bernd@firmix.at> wrote:

> Hi all!
> 
> Is there a specific reason that open can not open files (at
> least /proc/noatime and /proc/cpuinfo) under /proc with NO_ATIME as the
> following program shows:
> ----  snip  ----
> {12}cat noatime.c
> 
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <string.h>
> #include <errno.h>
> #include <fcntl.h>
> 
> int main(void)
> {
> 	int fd = open("/proc/uptime", O_RDONLY|O_NOATIME);
> 	if (fd == -1) {
> 		printf("fd=%d, errno=%s\n", fd, strerror(errno));
> 	} else {
> 		printf("fd=%d\n", fd);
> 	}
> 	return 0;
> }
> ----  snip  ----
> When I compile and run it, it prints
> ----  snip  ----
> {13}./noatime 
> fd=-1, errno=Operation not permitted
> ----  snip  ----
> Removing the "NO_ATIME" makes it work (of course).
> 
> I can also set the "noatime" mount flag on a remount and it shows up
> in /proc/mounts but it makes for the above no difference.
> 

I guess you're hitting the check in may_open():

	/* O_NOATIME can only be set by the owner or superuser */
	if (flag & O_NOATIME)
		if (!is_owner_or_cap(inode)) {
			error = -EPERM;
			goto err_out;
		}

This code was added in 2004 and neither the changelog nor the code
comment explain _why_ this was done (bad).  It might be recorded in the
contemporary email discussion.

I assume it was done this way under the assumption that people might
want to use atime to determine if other users have been peeking at
their junk.  Avoid permitting junk-peekers to conceal their tracks.

Re: O_NOATIME and files in /proc

[Alan Cox]

On Fri, 20 Nov 2009 13:36:51 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Tue, 17 Nov 2009 18:06:29 +0100
> Bernd Petrovitsch <bernd@firmix.at> wrote:
> 
> > Hi all!
> > 
> > Is there a specific reason that open can not open files (at
> > least /proc/noatime and /proc/cpuinfo) under /proc with NO_ATIME as the
> > following program shows:

Andreww: http://lkml.org/lkml/2004/6/14/184 seems to explain the origin
of this. To follow it further you'd need to discuss it with Ulrich I
imagine and see why glibc expected that behaviour and in turn where it
came from and what security or similar concerns were anticipated.

Alan

Re: O_NOATIME and files in /proc

[Bernd Petrovitsch]

On Fri, 2009-11-20 at 22:11 +0000, Alan Cox wrote:
> On Fri, 20 Nov 2009 13:36:51 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Tue, 17 Nov 2009 18:06:29 +0100
> > Bernd Petrovitsch <bernd@firmix.at> wrote:
[...]
> > > Is there a specific reason that open can not open files (at
> > > least /proc/noatime and /proc/cpuinfo) under /proc with NO_ATIME as the
> > > following program shows:
> 
> Andreww: http://lkml.org/lkml/2004/6/14/184 seems to explain the origin
> of this. To follow it further you'd need to discuss it with Ulrich I
What is the best to reach him?
Via drepper@gmail.com?

> imagine and see why glibc expected that behaviour and in turn where it
> came from and what security or similar concerns were anticipated.
Security reasons were the only issues I found there (and no links to
further papers/articles/motivation/literature).

For the more technical side (of the security concerns):
- I agree that it may be important to forcibly keep the atime (for files
  of other users including root) - at least for backups[0].
  However, I stumbled over it because I needed a file which changes
  over time for some periodic (as in every second) application
  and /proc/uptime was the first crossing my mind[1].
  Said application used O_NOATIME on each open() as it doesn't hurt
  anyways (and saves a little I/O - God knows how the root on the
  customers systems mounts filesystems).
  So the better solution in this case would have been to e.g. simply
  ignore the O_NOATIME flag (but make the open succeed). Yes, that
  can be solved in userspace too with a minimal wrapper function.

- *if* root (or whoever mounted it) already set "noatime" on a
  filesystem, the atime won't be updated anyways. So I can't see any
  security concern if the open() also requests O_NOATIME as it is not
  any change in behaviour.
  And since /proc/mounts is readable by any user, the user knows it.

- for procfs (and thus /proc): That seems to not store atime at all but
  returns always the "current" time.
  So I fail to see what rejecting O_NOATIME on procfs (for files of
  other users including root) may achieve.
  Perhaps it makes sense to judge this on a per-file basis.

Alas, perhaps selinux, capabilities and similar may invalid the above
thoughts (but I don't know enough of these extensive security frameworks
to comment on that).

	Bernd

[0]: I don't value "it can be proofed that user read the file" that
     much. Just knowing that a user open a given file doesn't imply that
     he actually read and actually understood it. Perhaps the user just
     misclicked the file and exited the filereader 0.5s after opening
     it.
[1]: Yes, that can also be solved differently - just more cumbersome.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services