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

Previous Next

Full log

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

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

Pádraig Brady wrote:
> That is true, but I confirmed that this is caused by "protected_hardlinks"
> Perhaps there is a blanket ban on symlinks if you're not the owner,
> since the symlink could be later changed to point somewhere more sensitive?
> Kees do you know if this is the case?
---
	If you have 'write' access to the symlink, I would say
yes, if not, then no.  however, traditionally, the ownership and permissions
on symlinks haven't been considered important.

	Still -- that I can link to a file but not a symlink is an
obvious flaw in the implementation.  I.e. I have write access to the
file -- so I should be able to link to it under their new rules,
but I also have write access to the symlink as the mode bits are 777.

	That's a bit bogus.  They are creating a special case where
there shouldn't be one.  I'm the directory owner -- I should be able
to create arbitrary 'entries' in the directory as I own the directory's
content -- that's been the tradition interpretation.

	Though the traditional rules never applied to symlinks -- and
now they've come up with an incompatible access method for symlinks...
If they really wanted to make them non-linkable, they should start
recognizing the mode bits on the symlink (to change the content of the
symlink -- which, in this case, is where it points).

Previous Next

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