On Sun, Nov 06, 2011 at 08:56:34AM -0500, Nico Kadel-Garcia wrote:
> Stefan, if I may suggest, special-casing file names is leaving trouble
> lying in wait.
Doing so was apparently git's idea, not ours.
> It would be safer to handle it via special file types.
> /dev/null is a "character special" filetype in UNIX and Linux,
> Character devices, block devices, and pipes should be ignored or
> cause errors when source control tries to manipulate them.
>
> /dev/null is unusual in that it has write and read access to all
> users, but I've seen too many cases where Subversion is being used by
> root logins to administer system files and has privileges to
> manipulate block devices, such as your disk drive. Rather than trying
> to guess what names such devices should have, why not block operations
> on a more powerful category that Subversion very clearly should not be
> touching?
Your concerns don't apply.
Firstly, 'svn patch' won't touch anything outside of the working copy
it is operating on (and yes, symlink attacks have been accounted for).
'svn patch' is not going to touch stuff in /dev or elsewhere even
if you're root.
In the provided example, /dev/null was stripped to "dev/null".
This resulted in a directory 'dev' and a file 'null' to be created in
the working copy. Neither existed before the patch was applied.
That's not wrong, it's basically what the patch says 'svn patch' should
do. Expect that "/dev/null" has special meaning in git patches and
therefore shouldn't be used as a patch target name.
Secondly, because Subversion's working copy meta data can only represent
files, directories, and symlinks, this is all you'll ever get with
'svn patch'. A device node or a pipe inside the working copy will look
like a regular unversioned node. And 'svn patch' won't touch unversioned
nodes. 'svn add' refuses to add device nodes or pipes -- it errors out
with "Unsupported node kind for path 'foo'."
So I don't follow how the scenario you describe can even happen.
Received on 2011-11-06 16:29:48 CET