bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17103: regression: cp -al doesn't copy symlinks, but tries to link t


From: Pádraig Brady
Subject: 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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

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.

Attachment: cp-handle-protected-hardlinks.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]