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

[Linda Walsh]

Paul Eggert wrote:
> Pádraig Brady wrote:
> > I'm not sure there is anything we should do here.
>
> I looked at <http://lwn.net/Articles/503671/> and as far as I can tell 
> symlinks are vulnerable to none of the attacks they mention, because 
> symlinks are unalterable.  However, the non-symlink hardlink attacks are 
> a real problem, and it would seem silly for cp -al to have a workaround 
> for symlinks (which I expect we can do reasonably safely) when cp can't 
> and shouldn't try to have a workaround for anything else.
---
No?

Why couldn't it create a device or other object under the user
account?

I.e. if I use a fifo in my build process at the top, -- all
that I need is for it to exist -- it doesn't need to be
and probably shouldn't be a hardlink.

cp has a workaround for directories and it has exactly this
workaround on other OS that don't support hardlinking.

I don't see why this shouldn't be treated similarly to the
2nd case, as the OS no longer supports hardlinking in as
many cases as it used to -- so why shouldn't it fall back?

If the user is IN a group that is setGID, then it can
be recreated under their UID, if it is another USER...
again, that might not be what is needed -- maybe it needs
to be the user who created the tree.

It is possible to work around most of those cases if not all.

But most important -- what % usage are those use cases for
cp -al?   I.e. copying tree's w/devices FIFOS et al that are
owned by someone else?

The dirs+files (regular) are the normal case, symlinks
can be done because it makes sense, the rest, I think should
be there as well, but don't care about as much.


> So I'm with you; let's leave this one alone.
---
core utils are becoming less functional and less core
with every new feature.  If you aren't flexible you'll
eventually have next to nada.