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

Previous Next

Full log

Message #47 received at 17103 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17103 <at> debbugs.gnu.org, Linda Walsh <coreutils <at> tlinx.org>
Subject: Re: bug#17103: regression: cp -al doesn't copy symlinks, but tries
 to link to them (fail)
Date: Thu, 27 Mar 2014 02:57:09 +0000

[Message part 1 (text/plain, inline)]

On 03/27/2014 12:57 AM, Paul Eggert wrote:
> Linda Walsh wrote:
>> if for some reason a symlink
>> cannot be linked to, then the symlink should be copied (not what
>> the symlink is pointing to, but the actual contents of the symlink
>> inode -- i.e. the redirection path).
> 
> Sure, but that's asking for different functionality than what's documented, and it's possible that others are relying on the documented behavior, so it's not clear how to proceed here.  Perhaps cp needs yet another option.  I hope not.

So this is a tricky one.

The specific restrictions with "protected_hardlinks" are at:
  http://lxr.linux.no/linux+v3.13.5/fs/namei.c#L751
One can see there that for files you don't own.
you can only hardlink them if they're non setuid regular files,
and if you can read and write them. So that excludes symlinks,
and fifos etc. as we've seen.

I think I see the reason for excluding symlinks here.
It's so one is able to remove a sensitive symlink and know there
are no more links to it that could be later replaced back.
Allowing that could bypass subsequent "protected_symlinks" checks.

Now we could fall back to creating separate symlinks,
like we do on systems that don't support hard links to symlinks.
This could be useful given that these less security
sensitive symlinks might be just as useful to the user.
I've attached a patch for illustration.

However I don't like it because it doesn't deal with,
1. fifos, device files, setuid regular files, nor,
2. relative symlinks that traverse outside the copied hierarchy.
3. Also if you were using `cp -al source mirror`, and subsequently
wanted to use the link count to see what was added in source,
then symlinks having a link count of only 1 would mess that up.

So given this is a system security policy that's restricting the operation,
and falling back to a less security sensitive operation has at least
the above 3 disadvantages, I'm not sure there is anything we should do here.

thanks,
Pádraig.

[cp-handle-protected-hardlinks.diff (text/x-patch, attachment)]

Previous Next

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