Directory Rename Path Overflow

[rdmark]

AFP Directory Rename Path Overflow Bug

Summary

Netatalk's AFP server can allow a directory rename or move that makes descendant
filesystem paths exceed the platform path limit. After that, descendants may
remain present in the CNID and dircache model but become inaccessible through
normal AFP operations by DID or parent/name.

This can leave the tree difficult or impossible to clean up via AFP and can
produce inconsistent errors such as AFPERR_MISC, AFPERR_ACCESS, and
AFPERR_DIRNEMPT.

Affected Area

• Directory rename/move: etc/afpd/filedir.c
• AFP FPMoveAndRename: etc/afpd/filedir.c
• DID path traversal: etc/afpd/directory.c
• Delete handling: etc/afpd/filedir.c
• Enumerate handling: etc/afpd/enumerate.c

Observed Behavior

A test creates a deeply nested but still addressable directory tree. Renaming
the top-level directory to a longer name pushes descendants over the platform
path limit. Afterward, cleanup attempts show failures like:

FPDelete did : 0x34 <>
AFPERR_MISC

FPEnumerate did : 0x34 <>
AFPERR_MISC

FPDelete did : 0x33 <full child name>
AFPERR_ACCESS

The parent directories remain non-empty, so recursive AFP cleanup cannot make
progress.

Expected Behavior

Netatalk should not allow an AFP rename or move that makes existing descendants
unaddressable through AFP. If the operation would exceed server filesystem path
limits, the server should reject the rename before changing visible state,
returning a stable AFP error.

Why This Appears Architectural

The server stores and reuses full directory paths in dircache and CNID state.
moveandrename() updates cached directory paths after rename, and later DID
operations use those full paths through movecwd().

If a renamed ancestor makes a descendant full path exceed the OS limit, DID
lookup may still resolve metadata, but path-based operations fail at the
filesystem boundary.

Impact

A client can create or trigger a state where a subtree is visible enough to
remain non-empty but no longer manageable through normal AFP delete and
enumerate operations. This is problematic for cleanup, administrative recovery,
and predictable AFP error semantics.

Suggested Hardening

1. Add a preflight for directory FPMoveAndRename: before renaming or moving a
   directory, determine whether any descendant full path would exceed the server
   platform path limit. Reject before the rename if so.
2. Add explicit ENAMETOOLONG handling in rename, delete, enumerate, and DID
   traversal paths. Avoid mapping it inconsistently to AFPERR_MISC or
   AFPERR_ACCESS.
3. Longer term, reduce reliance on absolute cached full paths for DID
   operations, favoring fd-relative traversal and openat-style operations
   where practical.

Regression Coverage

The updated FPMoveAndRename:test460 is a useful reproducer and regression
test. It dynamically constructs a tree that is valid before rename but crosses
MAXPATHLEN after renaming the top-level directory.