Bug 1091859

Summary: scrub-file can't handle link file
Product: Red Hat Enterprise Linux 6 Reporter: bfan
Component: libguestfsAssignee: Pino Toscano <ptoscano>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.5CC: huzhan, jherrman, leiwang, mbooth, ptoscano, rjones, wshi
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libguestfs-1.20.11-12.el6 Doc Type: Bug Fix
Doc Text:
The scrub-file API failed when attempting to handle symbolic links. With this update, scrub-file resolves the file path before handling it further, and as a result, using scrub-file on a symbolic link now properly affects the link's target.
Story Points: ---
Clone Of: 1091856 Environment:
Last Closed: 2015-07-22 05:55:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1099490    
Bug Blocks:    

Description bfan 2014-04-28 08:29:57 UTC
+++ This bug was initially created as a clone of Bug #1091856 +++

Description of problem:
scrub-file can't handle the link file, failed by "no rw access"


Version-Release number of selected component (if applicable):
libguestfs-1.22.6-22.el7.x86_64


How reproducible:
100%


Steps to Reproduce:
# guestfish -x -v -N fs -m /dev/sda1 write /test.log "hello" : ln-s /test.log /link.log : scrub-file /link.log

# [omitted logs]
libguestfs: trace: mount_options = 0
libguestfs: trace: write "/test.log" "hello"
libguestfs: trace: internal_write "/test.log" "hello"
guestfsd: main_loop: proc 74 (mount_options) took 0.00 seconds
guestfsd: main_loop: new request, len 0x44
guestfsd: main_loop: proc 246 (internal_write) took 0.00 seconds
libguestfs: trace: internal_write = 0
libguestfs: trace: write = 0
libguestfs: trace: ln_s "/test.log" "/link.log"
guestfsd: main_loop: new request, len 0x48
ln -s -- /test.log /sysroot/link.log
guestfsd: main_loop: proc 166 (ln_s) took 0.00 seconds
libguestfs: trace: ln_s = 0
libguestfs: trace: scrub_file "/link.log"
guestfsd: main_loop: new request, len 0x38
scrub -r /sysroot/link.log
scrub: no rw access to /sysroot/link.log
guestfsd: error: /link.log: scrub: no rw access to /sysroot/link.log
guestfsd: main_loop: proc 115 (scrub_file) took 0.00 seconds
libguestfs: trace: scrub_file = -1 (error)
libguestfs: error: scrub_file: /link.log: scrub: no rw access to /sysroot/link.log
libguestfs: trace: close
libguestfs: closing guestfs handle 0x7fe8766d7730 (state 2)
libguestfs: trace: internal_autosync
guestfsd: main_loop: new request, len 0x28
umount /sysroot
fsync /dev/sda
guestfsd: main_loop: proc 282 (internal_autosync) took 0.03 seconds
libguestfs: trace: internal_autosync = 0
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfsLzMSKl


Actual results:
libguestfs: error: scrub_file: /link.log: scrub: no rw access to /sysroot/link.log


Expected results:
scrub-file can handle link file like linux original command 'scrub'


Additional info:
Same problem exist in rhel6, libguestfs-1.20.11-2.el6.x86_64

# guestfish -N fs -m /dev/sda1 write /test.log "hello" : ln-s /test.log /link.log : scrub-file /link.log
libguestfs: error: scrub_file: /link.log: scrub: /sysroot/link.log does not exist

Comment 4 Hu Zhang 2014-12-10 09:35:32 UTC
Verified this bug with Packages version:
libguestfs-1.20.11-12.el6.x86_64

Verify steps:
1.guestfish -x -v -N fs -m /dev/sda1 write /test.log "hello" : ln-s /test.log /link.log : scrub-file /link.log
...
libguestfs: trace: mount_options = 0
libguestfs: trace: write "/test.log" "hello"
libguestfs: trace: internal_write "/test.log" "hello"
libguestfs: send_to_daemon: 72 bytes: 00 00 00 44 | 20 00 f5 f5 | 00 00 00 04 | 00 00 00 f6 | 00 00 00 00 | ...
guestfsd: main_loop: proc 74 (mount_options) took 0.06 seconds
guestfsd: main_loop: new request, len 0x44
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 f6 | 00 00 00 01 | 00 12 34 03 | ...
libguestfs: trace: internal_write = 0
libguestfs: trace: write = 0
libguestfs: trace: ln_s "/test.log" "/link.log"
libguestfs: send_to_daemon: 76 bytes: 00 00 00 48 | 20 00 f5 f5 | 00 00 00 04 | 00 00 00 a6 | 00 00 00 00 | ...
guestfsd: main_loop: proc 246 (internal_write) took 0.00 seconds
guestfsd: main_loop: new request, len 0x48
ln -s -- /test.log /sysroot/link.log
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 a6 | 00 00 00 01 | 00 12 34 04 | ...
libguestfs: trace: ln_s = 0
libguestfs: trace: scrub_file "/link.log"
libguestfs: send_to_daemon: 60 bytes: 00 00 00 38 | 20 00 f5 f5 | 00 00 00 04 | 00 00 00 73 | 00 00 00 00 | ...
guestfsd: main_loop: proc 166 (ln_s) took 0.00 seconds
guestfsd: main_loop: new request, len 0x38
scrub -r /sysroot/test.log
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 73 | 00 00 00 01 | 00 12 34 05 | ...
libguestfs: trace: scrub_file = 0
libguestfs: trace: shutdown
libguestfs: trace: internal_autosync
libguestfs: send_to_daemon: 44 bytes: 00 00 00 28 | 20 00 f5 f5 | 00 00 00 04 | 00 00 01 1a | 00 00 00 00 | ...
guestfsd: main_loop: proc 115 (scrub_file) took 0.07 seconds
guestfsd: main_loop: new request, len 0x28
umount /sysroot
fsync /dev/sda
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 01 1a | 00 00 00 01 | 00 12 34 06 | ...
libguestfs: trace: internal_autosync = 0
libguestfs: sending SIGTERM to process 11348
libguestfs: trace: shutdown = 0
libguestfs: trace: close
libguestfs: closing guestfs handle 0x138dcf0 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfsVpNeBg

As the log "libguestfs: trace: scrub_file = 0", no related error returned.

Verified.

Comment 6 errata-xmlrpc 2015-07-22 05:55:16 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1444.html