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

[Linda Walsh]

Some other thoughts on the rest...

Kees Cook wrote:
> Yeah, this is a poor interaction. The trouble with hardlinks is that
> they retain the original ownership.

> Seems like doing the fallback would serve most users best. Just keep
> it documented in the case of really weird stuff like above. Though
> this case of hardlink-copying a writable unowned tree is pretty
> unusual already! :)
---
        It was something that happened recently when I was
in a hurry to build a new tree -- permissions were failing so I
just made group root had write access (as was already in group
root).    So how it use to be, was that I didn't have write access
to the files, so I couldn't save edits w/o renaming the original
and then saving the edits as a new version.

        I spent more time tracking down the problem because I got
the error this time even with the group perms set... that lead me to
the hardlink->symlink practice...

        So the only reason I had write access was to get around
the first bits of this problem -- I wonder if they disallowed any
non-regular in a more recent update than when the other stuff went in.

        Either that or a package update from my vendor added the
default-on rule.

        I spent more time to investigate this time (as I
duped 3.13 -> 3.13.7 and applied patches) , because
I found that I didn't need to reapply a local patch to the last
kernel build w/new sources and that was because my changes now didn't
need to be made to a copy, but flowed right into the source tree for
any sub-releases dependent on that Maj-Min combo.  Oh well.  I.e.
I relied on the r/o access to keep myself inline... ;^).


> Yeah, it'd be nice if the symlink bits had meaning. However, relaxing
> this check on the kernel side results in bad scenarios, especially
> when combined with the symlink restrictions. e.g., creating a hardlink
> to a symlink that matches the directory owner in /tmp. Now an attacker
> controls the destination of a followable symlink.
---
Huh?   A symlink doesn't act like an SUID  (or has that
changed?)  -- if the object the symlink pointed to was write protected
against the user, they would still be hard pressed to exploit it.

How would having a pointer to the file (that still follows tree
traversal rules - i.e - only allowing access to paths the user could
gotten to anyway) confer new access rights to a user?