{"version":"2.1.238","anchor":"remote-file-reads-re-check-the-path-after-opening-it","canonical_anchor":"remote-file-reads-re-check-the-path-after-opening-it","heading":"Remote file reads re-check the path after opening it","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238\/e\/remote-file-reads-re-check-the-path-after-opening-it","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238","markdown":"### Remote file reads re-check the path after opening it\n\nRemote file reads re-check the path after opening, so a swapped symlink cannot slip through.\n\n**What**\n\nFile 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.\n\n**Details**\n\n- 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`.\n- 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.\n- 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.\n- The same helpers now back the bridge's request to seed read state.\n- No flag; applies to remote-surface reads.\n\n**Evidence**\n\n`read_file: untrusted UNC path rejected before filesystem access`\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}