Hacker News Reader

After resolving symbolic links that turns into "mv bar foo", which is perfectly acceptable since they are siblings. The checks for the destination being a descendant of the source should be performed after symlink resolution.

There's nothing in the standard about rename()'s error code priority (it could be EXDEV or EINVAL - they are not mutually exclusive), so I'd consider that a bug too.

View on HN

The kernel has to resolve the symbolic link - /bin/mv should not try because it cannot do so without a race.

Presuming that you wouldn't invoke mv nanoseconds before creating the symlink, I think mv should resolve the symlink first and, if the move doesn't make sense, abort. It will still need to handle the case where it looks like the move makes sense, but the kernel returns EINVAL or whatever.

> Presuming that you wouldn't invoke mv nanoseconds before creating the symlink

This kind of thinking has led to lots of security bugs around symlinks.

indeed, and not just symlinks.

being vigilant about not creating unnecessary race conditions is important. doubly so when you're building a tool upon which others will compose their own programs/scripts/etc.

Reply on news.ycombinator.com