Bug 717962

Summary: When copying directory into report using addCopySpec, links inside are not handled correctly
Product: Red Hat Enterprise Linux 5 Reporter: David Kutálek <dkutalek>
Component: sosAssignee: Bryn M. Reeves <bmr>
Status: CLOSED ERRATA QA Contact: David Kutálek <dkutalek>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.7CC: agk, bmr, gavin, lmiksik, prc
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: sos-1.7-9.59.el5 Doc Type: Bug Fix
Doc Text:
Cause: the internal API used by sos modules to collect files and directories incorrectly handled symbolic links with a relative target path. Consequence: due to this bug only the symbolic link (and not the file to which it refers) were copied into the sosreport tarball. Fix: the file and directory copying routines have been modified to correctly copy and adjust symbolic link targets within the sosreport tree. Result: Relative symbolic links are now handled correctly and their targets are properly included in the generated report.
Story Points: ---
Clone Of:
: 782589 (view as bug list) Environment:
Last Closed: 2012-02-21 03:25:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 769266, 782064, 782589    

Description David Kutálek 2011-06-30 14:30:38 UTC
Description of problem:

It seems to be a general problem, which shows eg in general plugin:
 - there is addCopySpec("/etc/sysconfig") statement
 - /etc/sysconfig/selinux is a link to /etc/selinux/config
 - because of this bug, only link is copied, resulting in missing real file and having broken link in report

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

sos-1.7-9.54.el5

How reproducible:

Always

Steps to Reproduce:
1. sosreport -o general
2. unpack report and list etc/sysconfig/selinux
3.
  
Actual results:

link is broken, destination file not present in report

Expected results:

destination file should be gathered, too

Additional info:

This is probably primary cause of somehow badly written bug report: bug 674717

Comment 1 Bryn M. Reeves 2011-11-09 12:15:13 UTC
Actually the links are copied exactly as they appear in the file system (i.e. there's no adjustment of the link target). This means that relative symlinks work fine but breaks absolute links.

On my RHEL5 test machines /etc/sysconfig links like selinux are all relative so I've not seen the problem in testing.

I'm still puzzled by bug 674717 though since that report shows a relative symlink:

Actual results:
lrwxrwxrwx 1 root root    17  2月  3 11:01 selinux -> ../selinux/config

In my testing I don't see a problem for this case:

# tar xf sosreport-pe1950-1-644170-cd9b6a.tar.bz2
# ls -l pe1950-1-644170/etc/sysconfig/selinux
lrwxrwxrwx 1 root root 17 Nov  9 11:51 pe1950-1-644170/etc/sysconfig/selinux -> ../selinux/config
# cat pe1950-1-644170/etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

Comment 2 Bryn M. Reeves 2011-11-09 18:01:31 UTC
sos has code to handle absolute symlinks that it encounters when processing addCopySpec'd paths:

    # Methods for copying files and shelling out
    def doCopyFileOrDir(self, srcpath):
[...]
            if os.path.isabs(link):
                # the link was an absolute path, and will not point to the new
                # tree. We must adjust it.
                rpth = sosRelPath(os.path.dirname(dstslname), os.path.join(self.cInfo['dstroot'], link.lstrip(os.path.sep)))
            else:
                # no adjustment, symlink is the relative path
                rpth = link
[...]

But this isn't working correctly for links that are added recursively (i.e. contained in a directory passed to addCopySpec - glob matches are handled correctly).

This is why I hadn't seen this in my testing - with all plugins enabled the general plugin will collect the symlink (but no target) and the selinux plugin will then finish the job since it calls addCopySpec("/etc/sysconfig/selinux") and triggers a copy of the target.

Comment 3 Bryn M. Reeves 2011-11-09 18:04:10 UTC
Hmm, no it's actually simpler than that. The symlink handling is just broken (just adjusts abs->rel but does not add the link target to the file set).

Other plugins only mask the behaviour if they coincidentally pull in the target path - e.g. selinux does addCopySpec("/etc/selinux") which will include the /etc/selinux/config file that the general plugin references as ../selinux/config.

Comment 4 Bryn M. Reeves 2011-11-09 18:11:51 UTC
Turns out to be a one-line fix:
 
diff -up sos/plugintools.py.orig sos/plugintools.py
--- sos/plugintools.py.orig     2011-11-09 18:04:34.000000000 +0000
+++ sos/plugintools.py  2011-11-09 18:04:17.000000000 +0000
@@ -174,6 +174,7 @@ class PluginBase:
 
             self.soslog.log(logging.VERBOSE3, "creating symlink %s -> %s" % (dstslname, rpth))
             os.symlink(rpth, dstslname)
+            self.doCopyFileOrDir(link)
             self.copiedFiles.append({'srcpath':srcpath, 'dstpath':rpth, 'symlink':"yes", 'pointsto':link})
             return

We need to explicitly request collection of the original symlink target path from the system.

Comment 11 Bryn M. Reeves 2012-01-26 12:10:02 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: the internal API used by sos modules to collect files and directories incorrectly handled symbolic links with a relative target path.

Consequence: due to this bug only the symbolic link (and not the file to which it refers) were copied into the sosreport tarball.

Fix: the file and directory copying routines have been modified to correctly copy and adjust symbolic link targets within the sosreport tree.

Result: Relative symbolic links are now handled correctly and their targets are properly included in the generated report.

Comment 12 errata-xmlrpc 2012-02-21 03:25:24 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.

http://rhn.redhat.com/errata/RHSA-2012-0153.html