linux-kernel - Re: [RFC 0/5] pathconf(3) with _PC_LINK

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]

Date:	Sun, 6 Dec 2009 08:39:58 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"J. R. Okajima" <hooanon05@...oo.co.jp>
Cc:	linux-kernel@...r.kernel.org, stewb@...ux-foundation.org
Subject: Re: [RFC 0/5] pathconf(3) with _PC_LINK_MAX

On Sun, Dec 06, 2009 at 04:58:58PM +0900, J. R. Okajima wrote:
> The pathconf(_PC_LINK_MAX) cannot get the correct value, since linux
> kernel doesn't provide such interface. And the current implementation in
> GLibc issues statfs(2) first and then returns the predefined value
> (EXT2_LINK_MAX, etc) based upoin the filesystem type. But GLibc doesn't
> support all filesystem types. ie. when the target filesystem is unknown
> to pathconf(3), it will return LINUX_LINK_MAX (127).
> For GLibc, there is no way except implementing this poor method.
> 
> This patch makes statfs(2) return the correct value via struct
> statfs.f_spare[0].

Um...  Why do we need that, again?  Note that there is no way whatsoever
for predicting whether link(2) will fail due to having too many existing
links before you attempt the call - links can be created or removed between
stat(2) and link(2).  So any uses of that value are heuristical.

Can you actually show any use cases of that thing?  Preferably - in existing
code, but even a theoretical one would be interesting.
--
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/