[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17103: regression: cp -al doesn't copy symlinks, but tries to link t
From: |
Linda Walsh |
Subject: |
bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail) |
Date: |
Wed, 26 Mar 2014 13:21:13 -0700 |
User-agent: |
Thunderbird |
Pádraig Brady wrote:
On 03/26/2014 06:08 PM, Linda Walsh wrote:
have a simple test case:
as root (w /umask 002):
mkdir -p dir/{a,b}
touch dir/b/file
ln -s ../b/file dir/a/symfile
---
So now tree should look like:
tree -AFugp dir
dir
+-- [drwxrwxr-x root root ] a/
| +-- [lrwxrwxrwx root root ] symfile -> ../b/file
+-- [drwxrwxr-x root root ] b/
+-- [-rw-rw-r-- root root ] file
----
Now, w/normal user, who is in group root, try:
cp -al dir dir2
cp: cannot create hard link ‘dir2/dir/a/symfile’ to ‘dir/a/symfile’: Operation
not permitted
-----
Trying to link to a symlink is the bug --
it used to duplicate the symlink.
This is a recent behavior
change -- i.e. looking at earlier behavior, the symlinks,
like the directories are created as the 'user', and
only files are linked to.
Core utils version: 8.21 (suse rpm coreutils-8.21-7.7.7.x86_64)
Any idea how this managed to be broken?
So I think the change to use hardlinks to symlinks rather than new symlinks
happened with:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=594292a1
I.E. The "new symlink" behaviour only happened between v8.0 and v8.10 inclusive.
So why is the hardlink to symlink being disallowed?
I wonder is it due to "protected_hardlinks":
http://danwalsh.livejournal.com/64493.html
----
As far as I know, you could never hardlink
to a symlink. only to a file. A symlink is more like
a directory in that regard.
Looking at the article, it doesn't seem it should apply...it
says
1) The solution is to permit symlinks to only be followed when outside a sticky
world-writable directory,
[it isn't in a sticky world writable directory] or when the uid of the
symlink and follower match, or when the directory owner matches the symlink's owner.
[in the created dir, the symlink and directory owner match]
2) The solution is to permit hardlinks to only be created when the user is
already the existing file's owner, or if they already have read/write access to
the existing file.
[ Already have r/w access to the file via being in group root and the group
having write access]
I think I did run into this change, though, and because of it, my system
is less secure. ... I.e. in my use case, am copying a source tree
into a 2nd tree. I am the directory owner of all dirs in the 2nd tree,
but all the source files should allow my linking to it as the permissions
on the inode protect the contents of the inode. The access to create a
hardlink to that inode has always been controlled by the directory owner,
but it never gives them write access to the content.
Their exploit case was for a stupid admin who chowned all files in a user's dir
"for them" -- why would that EVER be done? I.e. the root admin should
be immediately suspicious as to why they'd need that done. Since you
can't hardlink directories, the only way for a foreign owned directory
to get into someone's home space, would be if they opened the permissions
on the parent then later closed them.
The whole premise of their change relies on the user tricking the admin.
But if that's so easy, the user already has root access, effectively,
and the games up.
If we fell back to using symlinks, would that only
push the perm issue on to when the symlink was followed?
----
No, the file it points to, if you look at my example
is rw for the 'group' members.
- bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail), Linda Walsh, 2014/03/26
- bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail), Pádraig Brady, 2014/03/26
- bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail),
Linda Walsh <=
- bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail), Pádraig Brady, 2014/03/26
- bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail), Linda Walsh, 2014/03/26
- bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail), Kees Cook, 2014/03/27
- bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail), Linda Walsh, 2014/03/27
- bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail), Linda Walsh, 2014/03/27
- bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail), Kees Cook, 2014/03/28
- bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail), Linda Walsh, 2014/03/28