Message ID | 9bb10b607e46f867a3f8f5c71abf13c990d1ecfe.1676572031.git.me@ttaylorr.com (mailing list archive) |
---|---|
State | Accepted |
Commit | e00e56a7df616659c90d107c3d31d362b5dff103 |
Headers | show |
Series | dir-iterator: drop unused `DIR_ITERATOR_FOLLOW_SYMLINKS` | expand |
On Thu, Feb 16, 2023 at 01:27:14PM -0500, Taylor Blau wrote: > The `FOLLOW_SYMLINKS` flag was added to the dir-iterator API in > fa1da7d2ee (dir-iterator: add flags parameter to dir_iterator_begin, > 2019-07-10) in order to follow symbolic links while traversing through a > directory. > > `FOLLOW_SYMLINKS` gained its first caller in ff7ccc8c9a (clone: use > dir-iterator to avoid explicit dir traversal, 2019-07-10), but it was > subsequently removed in 6f054f9fb3 (builtin/clone.c: disallow `--local` > clones with symlinks, 2022-07-28). > > Since then, we've held on to the code for `DIR_ITERATOR_FOLLOW_SYMLINKS` > in the name of making minimally invasive changes during a security > embargo. > > In fact, we even changed the dir-iterator API in bffc762f87 > (dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS, > 2023-01-24) without having any non-test callers of that flag. > > Now that we're past those security embargo(s), let's finalize our > cleanup of the `DIR_ITERATOR_FOLLOW_SYMLINKS` code and remove its > implementation since there are no remaining callers. Thanks for following up on this. I think it's an obviously good direction, and the patch looks sensible. It's hard to grep for --follow-symlinks or FOLLOW_SYMLINKS to make sure you got everything, just because there are other unrelated features that use that name. ;) But I think you got all the relevant spots. The only thing I wondered is whether we could clean up any of the test setup. Specifically, "dir5" does not seem to be used in the tests, and everything passes with: diff --git a/t/t0066-dir-iterator.sh b/t/t0066-dir-iterator.sh index 4ed3136b00..1f3e070ec2 100755 --- a/t/t0066-dir-iterator.sh +++ b/t/t0066-dir-iterator.sh @@ -106,12 +106,6 @@ test_expect_success SYMLINKS 'setup dirs with symlinks' ' ln -s d dir4/a/e && ln -s ../b dir4/a/f && - mkdir -p dir5/a/b && - mkdir -p dir5/a/c && - ln -s ../c dir5/a/b/d && - ln -s ../ dir5/a/b/e && - ln -s ../../ dir5/a/b/f && - ln -s dir4 dir6 ' But...that is true even before your patch. dir5 is not mentioned in any of the expected output, even in fa1da7d2ee (dir-iterator: add flags parameter to dir_iterator_begin, 2019-07-10) where it was added. Was it just vestigial? Or is it somehow important that it is _not_ in the output? I didn't dig, and even if it can be removed, it would probably make sense to do it separately from your patch anyway. -Peff
On Thu, Feb 16, 2023 at 01:49:55PM -0500, Jeff King wrote: > Thanks for following up on this. I think it's an obviously good > direction, and the patch looks sensible. It's hard to grep for > --follow-symlinks or FOLLOW_SYMLINKS to make sure you got everything, > just because there are other unrelated features that use that name. ;) No problem. > But...that is true even before your patch. dir5 is not mentioned in any > of the expected output, even in fa1da7d2ee (dir-iterator: add flags > parameter to dir_iterator_begin, 2019-07-10) where it was added. Was it > just vestigial? Or is it somehow important that it is _not_ in the > output? > > I didn't dig, and even if it can be removed, it would probably make > sense to do it separately from your patch anyway. I have no idea either. From a cursory scan, I think I'd err on the side of it being vestigial. But Matheus (cc'd) should be able to tell us for sure. Thanks, Taylor
On Thu, Feb 16, 2023 at 03:03:01PM -0500, Taylor Blau wrote: > I have no idea either. From a cursory scan, I think I'd err on the side > of it being vestigial. But Matheus (cc'd) should be able to tell us for > sure. Oops. That email (Matheus Tavares <matheus.bernardino@usp.br>) is deactivated, which I should have known from 38645f8cb19 (mailmap: update email address of Matheus Tavares, 2022-12-09). I CC'd the right address instead. Thanks, Taylor
Hi, Taylor and Jeff On Thu, Feb 16, 2023 at 5:05 PM Taylor Blau <me@ttaylorr.com> wrote: > > On Thu, Feb 16, 2023 at 03:03:01PM -0500, Taylor Blau wrote: > > I have no idea either. From a cursory scan, I think I'd err on the side > > of it being vestigial. But Matheus (cc'd) should be able to tell us for > > sure. Oh, it's been some time. But yes, dir5 is vestigial and should indeed be removed. It was created back when I wanted to make dir-iterator detect and avoid recursive symlinks (see this [1] earlier version of the patch, where there was a test grepping for dir5 at the output). But this idea ended up being discarded and I must have forgotten to remove the dir5. [1]: https://lore.kernel.org/git/20190502144829.4394-7-matheus.bernardino@usp.br/
diff --git a/dir-iterator.c b/dir-iterator.c index 3764dd81a1..cedd304759 100644 --- a/dir-iterator.c +++ b/dir-iterator.c @@ -112,10 +112,7 @@ static int prepare_next_entry_data(struct dir_iterator_int *iter, iter->base.basename = iter->base.path.buf + iter->levels[iter->levels_nr - 1].prefix_len; - if (iter->flags & DIR_ITERATOR_FOLLOW_SYMLINKS) - err = stat(iter->base.path.buf, &iter->base.st); - else - err = lstat(iter->base.path.buf, &iter->base.st); + err = lstat(iter->base.path.buf, &iter->base.st); saved_errno = errno; if (err && errno != ENOENT) @@ -213,13 +210,10 @@ struct dir_iterator *dir_iterator_begin(const char *path, unsigned int flags) iter->flags = flags; /* - * Note: stat/lstat already checks for NULL or empty strings and + * Note: lstat already checks for NULL or empty strings and * nonexistent paths. */ - if (iter->flags & DIR_ITERATOR_FOLLOW_SYMLINKS) - err = stat(iter->base.path.buf, &iter->base.st); - else - err = lstat(iter->base.path.buf, &iter->base.st); + err = lstat(iter->base.path.buf, &iter->base.st); if (err < 0) { saved_errno = errno; diff --git a/dir-iterator.h b/dir-iterator.h index e3b6ff2800..479e1ec784 100644 --- a/dir-iterator.h +++ b/dir-iterator.h @@ -54,24 +54,8 @@ * and ITER_ERROR is returned immediately. In both cases, a meaningful * warning is emitted. Note: ENOENT errors are always ignored so that * the API users may remove files during iteration. - * - * - DIR_ITERATOR_FOLLOW_SYMLINKS: make dir-iterator follow symlinks. - * i.e., linked directories' contents will be iterated over and - * iter->base.st will contain information on the referred files, - * not the symlinks themselves, which is the default behavior. Broken - * symlinks are ignored. - * - * Note: setting DIR_ITERATOR_FOLLOW_SYMLINKS affects resolving the - * starting path as well (e.g., attempting to iterate starting at a - * symbolic link pointing to a directory without FOLLOW_SYMLINKS will - * result in an error). - * - * Warning: circular symlinks are also followed when - * DIR_ITERATOR_FOLLOW_SYMLINKS is set. The iteration may end up with - * an ELOOP if they happen and DIR_ITERATOR_PEDANTIC is set. */ #define DIR_ITERATOR_PEDANTIC (1 << 0) -#define DIR_ITERATOR_FOLLOW_SYMLINKS (1 << 1) struct dir_iterator { /* The current path: */ @@ -88,9 +72,7 @@ struct dir_iterator { const char *basename; /* - * The result of calling lstat() on path; or stat(), if the - * DIR_ITERATOR_FOLLOW_SYMLINKS flag was set at - * dir_iterator's initialization. + * The result of calling lstat() on path. */ struct stat st; }; diff --git a/t/helper/test-dir-iterator.c b/t/helper/test-dir-iterator.c index 659b6bfa81..6b297bd753 100644 --- a/t/helper/test-dir-iterator.c +++ b/t/helper/test-dir-iterator.c @@ -15,7 +15,7 @@ static const char *error_name(int error_number) /* * usage: - * tool-test dir-iterator [--follow-symlinks] [--pedantic] directory_path + * tool-test dir-iterator [--pedantic] directory_path */ int cmd__dir_iterator(int argc, const char **argv) { @@ -24,9 +24,7 @@ int cmd__dir_iterator(int argc, const char **argv) int iter_status; for (++argv, --argc; *argv && starts_with(*argv, "--"); ++argv, --argc) { - if (strcmp(*argv, "--follow-symlinks") == 0) - flags |= DIR_ITERATOR_FOLLOW_SYMLINKS; - else if (strcmp(*argv, "--pedantic") == 0) + if (strcmp(*argv, "--pedantic") == 0) flags |= DIR_ITERATOR_PEDANTIC; else die("invalid option '%s'", *argv); diff --git a/t/t0066-dir-iterator.sh b/t/t0066-dir-iterator.sh index 04b811622b..4ed3136b00 100755 --- a/t/t0066-dir-iterator.sh +++ b/t/t0066-dir-iterator.sh @@ -131,44 +131,10 @@ test_expect_success SYMLINKS 'dir-iterator should not follow symlinks by default test_cmp expected-no-follow-sorted-output actual-no-follow-sorted-output ' -test_expect_success SYMLINKS 'dir-iterator should follow symlinks w/ follow flag' ' - cat >expected-follow-sorted-output <<-EOF && - [d] (a) [a] ./dir4/a - [d] (a/f) [f] ./dir4/a/f - [d] (a/f/c) [c] ./dir4/a/f/c - [d] (b) [b] ./dir4/b - [d] (b/c) [c] ./dir4/b/c - [f] (a/d) [d] ./dir4/a/d - [f] (a/e) [e] ./dir4/a/e - EOF - - test-tool dir-iterator --follow-symlinks ./dir4 >out && - sort out >actual-follow-sorted-output && - - test_cmp expected-follow-sorted-output actual-follow-sorted-output -' - test_expect_success SYMLINKS 'dir-iterator does not resolve top-level symlinks' ' test_must_fail test-tool dir-iterator ./dir6 >out && grep "ENOTDIR" out ' -test_expect_success SYMLINKS 'dir-iterator resolves top-level symlinks w/ follow flag' ' - cat >expected-follow-sorted-output <<-EOF && - [d] (a) [a] ./dir6/a - [d] (a/f) [f] ./dir6/a/f - [d] (a/f/c) [c] ./dir6/a/f/c - [d] (b) [b] ./dir6/b - [d] (b/c) [c] ./dir6/b/c - [f] (a/d) [d] ./dir6/a/d - [f] (a/e) [e] ./dir6/a/e - EOF - - test-tool dir-iterator --follow-symlinks ./dir6 >out && - sort out >actual-follow-sorted-output && - - test_cmp expected-follow-sorted-output actual-follow-sorted-output -' - test_done
The `FOLLOW_SYMLINKS` flag was added to the dir-iterator API in fa1da7d2ee (dir-iterator: add flags parameter to dir_iterator_begin, 2019-07-10) in order to follow symbolic links while traversing through a directory. `FOLLOW_SYMLINKS` gained its first caller in ff7ccc8c9a (clone: use dir-iterator to avoid explicit dir traversal, 2019-07-10), but it was subsequently removed in 6f054f9fb3 (builtin/clone.c: disallow `--local` clones with symlinks, 2022-07-28). Since then, we've held on to the code for `DIR_ITERATOR_FOLLOW_SYMLINKS` in the name of making minimally invasive changes during a security embargo. In fact, we even changed the dir-iterator API in bffc762f87 (dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS, 2023-01-24) without having any non-test callers of that flag. Now that we're past those security embargo(s), let's finalize our cleanup of the `DIR_ITERATOR_FOLLOW_SYMLINKS` code and remove its implementation since there are no remaining callers. Signed-off-by: Taylor Blau <me@ttaylorr.com> --- dir-iterator.c | 12 +++--------- dir-iterator.h | 20 +------------------- t/helper/test-dir-iterator.c | 6 ++---- t/t0066-dir-iterator.sh | 34 ---------------------------------- 4 files changed, 6 insertions(+), 66 deletions(-)