Joel Becker wrote:
+ +Preserving the security context of the source file obviously requires +the privilege to do so. Callers that do not own the source file and do +not have CAP_CHOWN will get a new reflink with all non-security +attributes preserved; the security context of the new reflink will be +as a newly created file by that user. +
There are plenty of syscalls that require some privilege and fail if the caller doesn't have it. But I can think of only one syscall that does *something different* depending on who called it: setuid.
Please search the web and marvel at the disasters caused by setuid's magical caller-dependent behavior (the sendmail bug is probably the most famous [1]). This proposal for reflink is just asking for bugs where an attacker gets some otherwise privileged program to call reflink but to somehow lack the privileges (CAP_CHOWN, selinux rights, or whatever) to copy security attributes, thus exposing a link with the wrong permissions.
Would it really be that hard to have two syscalls, or a flag, or whatever, where one of them preserves all security attributes and *fails* if the caller isn't allowed to do that and the other one makes the caller own the new link?
[1] http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
