linux-kernel - PROBLEM: no ENOENT from utimensat with UTIME

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAJgzZooYNtdFmZkSBgu8HgOjW2Qr-ZUBUEgZC2mVpLTh7cUqRQ@mail.gmail.com>
Date:	Sun, 18 Jan 2015 10:56:00 -0800
From:	enh <enh@...gle.com>
To:	linux-kernel@...r.kernel.org
Subject: PROBLEM: no ENOENT from utimensat with UTIME_OMIT

utimensat always returns success if both times are UTIME_OMIT, even if
the file doesn't exist or dirfd is invalid.

$ cat x.c
#include <fcntl.h>
#include <sys/stat.h>

int main(int argc, char* argv) {
 struct timespec times[2] = { { 0, UTIME_OMIT }, { 0, UTIME_OMIT } };
 struct stat sb;

 stat("does-not-exist", &sb); // -ENOENT
 utimensat(AT_FDCWD, "does-not-exist", times, 0); // 0!
 utimensat(-1, "does-not-exist", times, 0); // 0!
 stat("does-not-exist", &sb); // -ENOENT

 return 0;
}
$ cc x.c -o x
$ strace -e stat,utimensat ./x
stat("does-not-exist", 0x7fff240d9190)  = -1 ENOENT (No such file or directory)
utimensat(AT_FDCWD, "does-not-exist", {UTIME_OMIT, UTIME_OMIT}, 0) = 0
utimensat(-1, "does-not-exist", {UTIME_OMIT, UTIME_OMIT}, 0) = 0
stat("does-not-exist", 0x7fff240d9190)  = -1 ENOENT (No such file or directory)
+++ exited with 0 +++
$

the above output is from a 3.13 kernel, but the bug is present at ToT:

https://github.com/torvalds/linux/blob/master/fs/utimes.c#L194

POSIX says "If both tv_nsec fields are set to UTIME_OMIT, no ownership
or permissions check shall be performed for the file, but other error
conditions may still be detected (including [EACCES] errors related to
the path prefix)." so i think that the "may" there means that strictly
this is in spec, but it's somewhat unhelpful.

fwiw, NetBSD seems to have the opposite mistake: they unconditionally
call namei so it would appear that they'll return errors for files
that do exist but where the caller doesn't have permission.

 --elliott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/