Remote file reads re-check the path after opening, so a swapped symlink cannot slip through.
What's wrong with this entry?
File reads requested by a remote or bridge session go through a much stricter path. The raw path, its resolved form and every parent directory are screened for four shapes: Windows NT-namespace paths, untrusted network (UNC) paths, untrusted automount paths and suspicious Windows spellings. After opening, the file's identity is re-checked and permission rules re-run against the real path, so swapping a symlink mid-read does not get you a different file.
- Files are opened read-only, non-blocking and without becoming a controlling terminal; device and inode are compared and the real path re-derived through
/proc/self/fd. - Read permission and ask-rules are evaluated a second time against that canonical path before any bytes are returned, and the read is byte-bounded.
- Every failure collapses to the same message shape, for example "read_file: untrusted UNC path rejected before filesystem access", so the rejected path is never echoed back.
- The same helpers now back the bridge's request to seed read state.
- No flag; applies to remote-surface reads.
read_file: untrusted UNC path rejected before filesystem access
Strings lifted out of the shipped bundle, so the claim above can be checked against them.