Hacker Newsnew | past | comments | ask | show | jobs | submitlogin



This paper, depending on how you look at it, either justifies the existence of dot dot, or makes it seem like a wart. IMO dot dot is too well-established and essentially sensible (in a minimal UNIX fashion) for it to be removed on a whim. Consider the approach taken by https://man.openbsd.org/unveil.2: if you try to access a file you aren't explicitly allowed to, you get EACCESS or ENOENT. I'm not an expert, and the possibility of errors obviously requires applications to tread more carefully than they might have previously, but it seems like a clean solution.


> removed on a whim

They changed the whole concept of having one single root. As I understand the plan is to use many fragmented and independent filesystem handles that can optionally mounted together.

So the restriction is more about non being able to access a folder if you don't have access to an appropriate handle.

Paths like folder1/folder2/../folder2/file are still perfectly fine.


To clarify: that's the Plan 9 situation. I'm talking about the merits of the Fuchsia situation (".. is no longer available").

References to a forbidden parent directory from a chroot can just return ENOENT, because it doesn't exist in that universe. I may not be understanding this fully, but to condemn ".." based on some accusation that it's incompatible with chroot semantics (or "a holdout from POSIX") seems tendentious.


Didn't MS-DOS already do this with letters? (e.g., a:, b:, c:)

Maybe I don't really understand Fuchsia's approach. But I do really like OpenBSD's approach in unveil.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: