On May 18, 2026, at 11:22, Cyber_black [off-list ref] wrote:

Thank you for raising this important question, Andy. I've been following the discussion as a "listening guest" and I have a thought.

My idea is this: Instead of forcing FIEMAP to become a root-only interface (breaking existing tools), or leaving it as-is (with information disclosure), what if we design a new, restricted API that is not privileged but also not unprivileged in the traditional sense?

What is the *actual* security risk of showing block numbers to users for their own files?

If an attacker can access the underlying device/image, they could directly use debugfs
or other filesystem tools to get file->block mappings anyway, and could modify the image
arbitrarily.  Restricting FIEMAP to root or obscuring block numbers is security through
obscurity and provides no actual safety.

Cheers, Andreas

Concretely:

1.  The API would be callable by any user, but it would not expose physical block addresses.

2.  It would answer higher-level questions that tools actually need, such as:

   -   "Are these two file ranges reflinked (shared)?" (for deduplication)

   -   "Is this file range sparse (holes)?" (without leaking physical locations)

   -   "What is the allocation status (delayed, unwritten, etc.)?"

3.  The kernel would maintain a capability or permission that is not root-equivalent (e.g., a new `CAP_BLOCK_MAP_QUERY`), but the API would not require full `CAP_SYS_RAWIO`.


This way:

-   Tools like `filefrag`, `cp`, and deduplication utilities can work without root.

-   Physical block addresses remain hidden from unprivileged users, closing the information leak.

-   We avoid forcing users to run these tools as root, which would open up far more serious risks (e.g., kernel panic, accidental corruption).


In short: we don't need to choose between "unprivileged leak" and "root-only". We can design a purpose‑limited API that answers only the necessary questions, with the minimum privilege required.

Would this be acceptable? I'd be happy to help draft a more detailed proposal or prototype.

This idea was developed together with my friend playerofficial19 (moybs027@gmail.com) through discussion. We hope it's helpful.

Cheers, Andreas