Bug 895910 - guestmount: rename() incorrectly follows symbolic links
Summary: guestmount: rename() incorrectly follows symbolic links
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 892834
TreeView+ depends on / blocked
 
Reported: 2013-01-16 09:19 UTC by Richard W.M. Jones
Modified: 2013-01-21 17:00 UTC (History)
8 users (show)

Fixed In Version:
Clone Of: 892834
Environment:
Last Closed: 2013-01-21 17:00:47 UTC
Embargoed:


Attachments (Terms of Use)
rename.sh (251 bytes, text/plain)
2013-01-21 15:41 UTC, Richard W.M. Jones
no flags Details

Description Richard W.M. Jones 2013-01-16 09:19:42 UTC
+++ This bug was initially created as a clone of Bug #892834 +++

Description of problem:

My project ostree implements atomic upgrades by swapping symbolic links.  However, rename() incorrectly follows the symbolic link, instead of overwriting the target.

Version-Release number of selected component (if applicable):

libguestfs-1.16.34-2.el6.x86_64
fuse-2.8.3-4.el6.x86_64
kernel-2.6.32-350.el6.x86_64

How reproducible:

Always.

Expected results (ext4):

$ mkdir adir
$ mkdir bdir
$ ln -s adir current
$ ln -s bdir new
$ mv -T -f new current
$ ls -al
total 16
drwxrwxr-x. 4 walters walters 4096 Jan  7 18:44 .
drwxrwxr-x. 4 walters walters 4096 Jan  7 18:42 ..
drwxrwxr-x. 2 walters walters 4096 Jan  7 18:42 adir
drwxrwxr-x. 2 walters walters 4096 Jan  7 18:42 bdir
lrwxrwxrwx. 1 walters walters    4 Jan  7 18:44 current -> bdir
$ 

Actual results (guestfs):

$ ls -al
total 16
drwxr-xr-x.  2 root root 4096 Jan  7 17:45 .
drwxr-xr-x. 12 root root 4096 Jan  7 17:45 ..
drwxrwxr-x.  2 root root 4096 Jan  7 18:47 adir
drwxrwxr-x.  2 root root 4096 Jan  7 18:46 bdir
lrwxrwxrwx.  1 root root    4 Jan  7 18:46 current -> adir
$ ls -al adir
total 8
drwxrwxr-x. 2 root root 4096 Jan  7 18:47 .
drwxr-xr-x. 4 root root 4096 Jan  7 18:47 ..
lrwxrwxrwx. 1 root root    4 Jan  7 18:46 new -> bdir

(where "new" is a broken symbolic link).

Note to testers: the -T argument to "mv" is important, it will ensure we just use the kernel rename() call instead of following the target.

--- Additional comment from RHEL Product and Program Management on 2013-01-07 19:04:32 EST ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Mohua Li on 2013-01-11 01:20:10 EST ---

 could reproduce in a guestmount mountpoint compare to the host filesystem,

--- Additional comment from RHEL Product and Program Management on 2013-01-14 01:47:53 EST ---

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 1 Richard W.M. Jones 2013-01-21 15:41:46 UTC
Created attachment 684374 [details]
rename.sh

A self-contained script that demonstrates the bug.

Compare the output to the 'actual' and 'expected' cases above.

Comment 2 Richard W.M. Jones 2013-01-21 15:47:39 UTC
Running guestmount with the --trace option shows the following
API calls are made (I omitted some non-essential calls):

+ mkdir adir
libguestfs: trace: mkdir_mode "/adir" 509
libguestfs: trace: mkdir_mode = 0
+ mkdir bdir
libguestfs: trace: mkdir_mode "/bdir" 509
libguestfs: trace: mkdir_mode = 0
+ ln -s adir current
libguestfs: trace: ln_s "adir" "/current"
libguestfs: trace: ln_s = 0
+ ln -s bdir new
libguestfs: trace: ln_s "bdir" "/new"
libguestfs: trace: ln_s = 0
+ mv -T -f new current
libguestfs: trace: mv "/new" "/current"
libguestfs: trace: mv = 0


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