site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi, Michael Roitzsch _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I just learned about the behavior of rename(2) on Darwin with respect to renaming directories. The manpage says in the Conformance Section, that renaming a directory not only requires write permission to the parent directory, but also to the directory being renamed. The first restriction is intuitively clear, the second is not. The reason given is that historically, UFS required write access to the ".." entry in the "renamee" and HFS+ today emulates this behavior. My question is: Is this behavior we can rely upon or could this disappear without notice? Or is it even file system specific? (Linux for example only checks the permissions of the parent on rename.) The reason I ask is that I have found at least one third party application relying on this behavior to be secure. That is: Code executed in a root context is stored in a path a user could mess with, if that additional rename restriction was not in place. Is it safe to do this? This email sent to site_archiver@lists.apple.com