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

Previous Next

Full log

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

From: Linda Walsh <coreutils <at> tlinx.org>
To: Kees Cook <keescook <at> google.com>
Cc: 17103 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>
Subject: Re: bug#17103: regression: cp -al doesn't copy symlinks,
 but tries to link to them (fail)
Date: Thu, 27 Mar 2014 19:25:21 -0700

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?

Previous Next

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