linux-kernel - Re: [Bugme-new] [Bug 14832] New: futimens (AT

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87vdfwk51p.fsf@devron.myhome.or.jp>
Date:	Thu, 24 Dec 2009 20:03:14 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Eric Blake <ebb9@....net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	bugzilla-daemon@...zilla.kernel.org,
	bugme-daemon@...zilla.kernel.org,
	Ulrich Drepper <drepper@...hat.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Michael Kerrisk <mtk.manpages@...glemail.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [Bugme-new] [Bug 14832] New: futimens (AT_FDCWD, arg) should fail

Eric Blake <ebb9@....net> writes:

>> afacit, if filename==NULL and dfd==-1 then fget() will return NULL and
>> the syscall returns -EBAFD.
>
> Yes, that's true if dfd==-1.  But My complaint was not about dfd==-1, but
> about dfd==AT_FDCWD, in which case, this block of code is skipped, and you
> end up operating on the current directory ".".  My point is that the line:
>  if (filename == NULL && dfd != AT_FDCWD) {
> should probably be:
>  if (filename == NULL) {
> assuming that fget(AT_FDCWD) likewise fails.

No, it changes utimensat() behavior. If error was EBADF, it seems fd
shouldn't be AT_FDCWD. So, this behavior would be right thing as
utimensat().

[EBADF] The path argument does not specify an absolute path and the fd
    argument is neither AT_FDCWD nor a valid file descriptor open for
    reading or searching.

>> Your report doesn't tell us what kernel version you're testing.  We did
>> fix a few things ni this area, but it was a long time ago.
>
> Yesterday, Ulrich patched glibc to avoid the issue from the library side
> of things (I first raised the report against glibc 2 months ago, along
> with a proposed patch:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=10992).  But there is
> still the case of newer kernels and unpatched glibc, where it would also
> be nice to patch the kernel.  I reproduced the bug on
> 2.6.31.6-166.fc12.i686, where this test (part of coreutils' configure
> script) failed with status 2:

-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
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/