GNU bug report logs - #17103
cp: "cp -al" doesn't copy symlinks, tries to link to them

Previous Next

Full log

View this message in rfc822 format

From: Linda Walsh <coreutils <at> tlinx.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 17103 <at> debbugs.gnu.org
Subject: bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail)
Date: Wed, 26 Mar 2014 13:21:13 -0700

Pádraig Brady wrote:
> On 03/26/2014 06:08 PM, Linda Walsh wrote:
>> have a simple test case:
>> as root (w /umask 002):
>>
>> mkdir -p dir/{a,b}
>> touch dir/b/file
>> ln -s ../b/file dir/a/symfile
>> ---
>>
>> So now tree should look like:
>>
>>>  tree -AFugp dir
>> dir
>> +-- [drwxrwxr-x root     root    ]  a/
>> |   +-- [lrwxrwxrwx root     root    ]  symfile -> ../b/file
>> +-- [drwxrwxr-x root     root    ]  b/
>>     +-- [-rw-rw-r-- root     root    ]  file
>> ----
>>
>> Now, w/normal user, who is in group root, try:
>>
>> cp -al dir dir2
>> cp: cannot create hard link ‘dir2/dir/a/symfile’ to ‘dir/a/symfile’: Operation not permitted
>> -----
>>
>> Trying to link to a symlink is the bug --
>> it used to duplicate the symlink.
>>
>> This is a recent behavior
>> change -- i.e. looking at earlier behavior, the symlinks,
>> like the directories are created as the 'user', and
>> only files are linked to.
>>
>> Core utils version: 8.21 (suse rpm coreutils-8.21-7.7.7.x86_64)
>>
>> Any idea how this managed to be broken?
> 
> So I think the change to use hardlinks to symlinks rather than new symlinks happened with:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=594292a1
> 
> I.E. The "new symlink" behaviour only happened between v8.0 and v8.10 inclusive.
> 
> So why is the hardlink to symlink being disallowed?
> I wonder is it due to "protected_hardlinks":
> http://danwalsh.livejournal.com/64493.html
----
	As far as I know, you could never hardlink
to a symlink.  only to a file.  A symlink is more like
a directory in that regard.

Looking at the article, it doesn't seem it should apply...it
says
1) The solution is to permit symlinks to only be followed when outside a sticky 
world-writable directory,
   [it isn't in a sticky world writable directory] or when the uid of the 
symlink and follower match, or when the directory owner matches the symlink's owner.
    [in the created dir, the symlink and directory owner match]
2) The solution is to permit hardlinks to only be created when the user is 
already the existing file's owner, or if they already have read/write access to 
the existing file.
   [ Already have r/w access to the file via being in group root and the group
having write access]

I think I did run into this change, though, and because of it, my system
is less secure.  ... I.e. in my use case, am copying a source tree
into a 2nd tree.  I am the directory owner of all dirs in the 2nd tree,
but all the source files should allow my linking to it as the permissions
on the inode protect the contents of the inode.  The access to create a
hardlink to that inode has always been controlled by the directory owner,
but it never gives them write access to the content.

Their exploit case was for a stupid admin who chowned all files in a user's dir 
"for them" -- why would that EVER be done?   I.e. the root admin should
be immediately suspicious as to why they'd need that done.  Since you
can't hardlink directories, the only way for a foreign owned directory
to get into someone's home space, would be if they opened the permissions
on the parent then later closed them.

The whole premise of their change relies on the user tricking the admin.

But if that's so easy, the user already has root access, effectively,
and the games up.


> 
> If we fell back to using symlinks, would that only
> push the perm issue on to when the symlink was followed?
----
	No, the file it points to, if you look at my example
is rw for the 'group' members.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.