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

[Linda Walsh]

Eric Blake wrote:
> On 03/26/2014 10:44 PM, Linda Walsh wrote:
>
> > cp has a workaround for directories and it has exactly this
> > workaround on other OS that don't support hardlinking.
>
> That "workaround" is behavior mandated by POSIX, and has existed prior
> to POSIX even being standardized.
>
> > 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?
>
> It's better to not second guess the kernel; you may want to take this up
> on the kernel lists if you want something changed.
---
It's not second guessing -- it's responding to a lower capability (or less
privileged) environment.  It also depends on whether or not those features are 
turned on (i.e. by assigning 0/1 to 
/proc/sys/fs/paranoid_protected_{hard,soft}links).  AFAIK, my vendor may have 
them set somewhere in boot code I haven't audited ( -- I've never had a need to 
audit my startup code till they started forcing systemd down everyone's throat
and putting dummy wrapper calls in the sysVinit code).

I.e. they've converted it from a system where doing a 'cp -al' worked
reliably to one where it doesn't.  If it doesn't work reliably, then it seems 
the, *cough*, posix mandate should followed....

But the outcome would be that cp would still just work -- just within the
bounds of what it is allowed to do.  Instead the attitude seems to be, gosh
if we can't have it the way it was, we shouldn't try to have it all.

The kernel bug is a separate issue -- since I CAN link to the file (permissions
allow it), but the same permissions on the link are ignored.

Note -- I grant that permissions ANd ownership on symlinks have always
been ignored (at least in experience), but if they are going to start
using permissions to enable/disallow hardlinking, maybe they shouldn't carve
out a special exception for symlinks.

But those are separate for how cp should behave on filesystems with varying,
"assumed" capabilities...(i.e. failing because one can't link to a symlink
when linking to symlinks isn't a requirement for this to be allowed on
systems that don't support symlinking at all).  I.e. as it stands, the ability
to hardlink to a file is dependent on what features and policies your
kernel has built in.  Cp should work as well as possible regardless of
those policies.

I.e. what is the posix policy for handling linking requests when the OS has 
disabled them?  If they wanted to disable copying the tree, they would make
it non-readable.