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?

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.