Bug 6749 - restoring a symlink changes owner/group of the target file
restoring a symlink changes owner/group of the target file
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: dump (Show other bugs)
6.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-05 05:33 EST by Chris Siebenmann
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-03 13:44:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Siebenmann 1999-11-05 05:33:06 EST
When restore is restoring symlinks, it winds up changing
the ownership and the group of the file the symlink points
at, instead of the owner/group of the symlink itself.

 Reproduction: reproduction may be somewhat difficult,
because you need to arrange that the symlink will be
later in the dump than the file it points at. On many
systems, doing (as a normal user) something like:
	cd /tmp; ln -s / foobar
[root runs dump & restores somewhere]
is likely to work -- but if you do this to test, remember
to fix the ownership of / afterwards!

 I consider this a security issue because in multi-user
environments where the operators or system administrators
will restore deleted/lost files for people, a nasty user
can exploit this to change the ownership of important
system files such as /etc/passwd to themselves, eg:
	evil$ ln -s /etc/passwd src/important/test-3
[wait for a backup to run]
	evil$ rm -rf src/important
	evil$ mail -s 'restore request' root
	I've lost my $HOME/src/important source tree;
	can you restore it from backups?
	^D
[wait for restore...]
	evil$ vi /etc/passwd # time for root2 to appear

Fix: use lchown() instead of chown() when restoring the
ownership/group of symlinks.
Comment 1 bjn 2000-01-19 09:35:59 EST
Apparently the author has seen this also; he says in the attached that all
versions (including 0.3, used in RedHat 5.2) are vulnerable, and that 0.4b9
fixes it to use lchown():

http://lwn.net/1999/1111/a/dump.html

Is a new RPM in the works?
Comment 2 Jeff Johnson 2000-01-19 09:50:59 EST
lchown does not work on stock Red Hat 5.2 systems, so the "fix" is
upgrading to Red Hat 6.0 (or upgrading glibc kernel and a bunch more).
Comment 3 Elliot Lee 2000-02-03 13:44:59 EST
jbj indicates that this problem is solved in the current release.

Note You need to log in before you can comment on or make changes to this bug.