linux-kernel - Re: [d_path 0/7] Fixes to d

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

Message-ID: <a36005b50704211246x339415d1wcb9dac8c2239b692@mail.gmail.com>
Date:	Sat, 21 Apr 2007 12:46:34 -0700
From:	"Ulrich Drepper" <drepper@...il.com>
To:	"Andreas Gruenbacher" <agruen@...e.de>
Cc:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [d_path 0/7] Fixes to d_path: Respin

On 4/21/07, Andreas Gruenbacher <agruen@...e.de> wrote:
> What I described is a supported feature, nothing more and nothing less. It's
> also relatively easy to handle this case correctly in glibc, e.g., [...]

This is only useful if the requirement of an ordered /proc/mounts is
part of the kernel ABI.  I.e., until somebody specifies (in the
sources, in kernel docs, I don't care where exactly) that the entries
in /proc/mounts appear in the order in which the mounts happened this
change is not better than the current code.  I have never found such
an assurance.

> This is what POSIX says about statvfs / fstatvfs:
> > It is unspecified whether all members of the statvfs structure have
> > meaningful values on all file systems.

Sure, just like POSIX in many other place leaves things unspecified.
This does not change the fact that we do a good job now.  You try to
use this wording to excuse the fact that you want to make the results
worse than they are now.  That's *not* the intend of this wording.

> In my opinion, the advantage of not reporting bogus pathnames in /proc/mounts
> by far outweighs the problems is sometimes causes for fstatvfs().

Hell no.  It is never acceptable to deliberately break compatibility.
Effects of bugs on the ABI might change but this is not the case here.
 This is an interface which forever displayed the information in this
form and it is correct and useful.
-
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/