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
On Tue, 17 Nov 2009 18:06:29 +0100
Bernd Petrovitsch <[email protected]> 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.
On Fri, 20 Nov 2009 13:36:51 -0800
Andrew Morton <[email protected]> wrote:
> On Tue, 17 Nov 2009 18:06:29 +0100
> Bernd Petrovitsch <[email protected]> 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
On Fri, 2009-11-20 at 22:11 +0000, Alan Cox wrote:
> On Fri, 20 Nov 2009 13:36:51 -0800
> Andrew Morton <[email protected]> wrote:
> > On Tue, 17 Nov 2009 18:06:29 +0100
> > Bernd Petrovitsch <[email protected]> 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 [email protected]?
> 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