Bug 717962 - When copying directory into report using addCopySpec, links inside are not handled correctly
Summary: When copying directory into report using addCopySpec, links inside are not ha...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sos
Version: 5.7
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Bryn M. Reeves
QA Contact: David Kutálek
URL:
Whiteboard:
Depends On:
Blocks: 769266 782064 782589
TreeView+ depends on / blocked
 
Reported: 2011-06-30 14:30 UTC by David Kutálek
Modified: 2012-02-21 03:25 UTC (History)
5 users (show)

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.
Clone Of:
: 782589 (view as bug list)
Environment:
Last Closed: 2012-02-21 03:25:24 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0153 0 normal SHIPPED_LIVE Low: sos security, bug fix, and enhancement update 2012-02-21 07:25:08 UTC

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


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