[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fts in gnulib behave different than glibc
From: |
Jim Meyering |
Subject: |
Re: fts in gnulib behave different than glibc |
Date: |
Wed, 28 Jul 2021 22:42:53 -0700 |
On Wed, Jul 28, 2021 at 1:08 AM Simon Josefsson via Gnulib discussion
list <bug-gnulib@gnu.org> wrote:
> Hi. I replaced GNU InetUtils' old custom fts implementation with the
> one from gnulib, but self-tests started failing. Looking at the code,
> it seems gnulib's fts implementation has diverged compared to glibc, and
> has some optimizations that (I think) change the API (wrt stat and
> chdir). Also, gnulib's fts module is always enabled, even on modern
> glibc systems. InetUtils's usage of fts works fine with modern glibc,
> but it didn't work with gnulib's version (it needed a FTS_NOCHDIR). The
> gnulib manual for the fts replacement module isn't terribly clear about
> this. Is there a reason for this behaviour?
>
> I would prefer if there were two fts modules in gnulib:
>
> 1) One module 'fts' based on glibc's code, that is only enabled in on
> systems that doesn't have fts, or where fts is known to be buggy.
>
> 2) One 'fts-faster' that is the current code, which can be used when you
> always wants to pull in the optimized implementation.
>
> Then InetUtils would use system fts on glibc platforms, and not always
> have to pull in a replacement copy.
>
> What do you think?
>
> I could live with a new module 'fts-optional' that only pulls in the
> current 'fts' module when the system is lacking it. That doesn't fix
> the API confusion, but is probably sufficient for InetUtils.
There are fundamental flaws in the ABI of glibc's fts that make it
unsuitable for use in any tool I care about.
Those flaws make it easy to hit silly limits or to provoke inordinate
resource usage/DoS.
Is it ok for InetUtil's fts to be unable to do these things? (each of
which afflicts glibc fts, from what I recall)
- process files in a tree more than 2^16 levels deep
- detect certain cycles efficiently
- delete (in reasonable time) a hierarchy with too many entries in a
single directory.