Re: [RFC] The reflink(2) system call v4.

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html