Re: O_NOATIME and files in /proc

[Bernd Petrovitsch <bernd@firmix.at>]

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