User: Password:
Subscribe / Log in / New account

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

From:  Andy Lutomirski <>
To:  jim owens <>,,,,,,
Subject:  Re: [RFC] The reflink(2) system call v4.
Date:  Wed, 13 May 2009 23:57:58 -0400
Message-ID:  <>
Archive-link:  Article

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?


To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to
More majordomo info at

(Log in to post comments)

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds