O_NOATIME and files in /proc
Bernd Petrovitsch
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
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.
Alan Cox
Andrew Morton <ak...@linux-foundation.org> wrote:
> On Tue, 17 Nov 2009 18:06:29 +0100
> Bernd Petrovitsch <be...@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
Bernd Petrovitsch
> On Fri, 20 Nov 2009 13:36:51 -0800
> Andrew Morton <ak...@linux-foundation.org> wrote:
> > On Tue, 17 Nov 2009 18:06:29 +0100
> > Bernd Petrovitsch <be...@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
Via dre...@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