Bug 1361269

Summary: SymlInk target overwritten when the symlink is replaced by a file managed by rhncfg-client
Product: Red Hat Satellite 5 Reporter: Radovan Drazny <rdrazny>
Component: Configuration ManagementAssignee: Eric Herget <eherget>
Status: CLOSED CURRENTRELEASE QA Contact: Lukáš Hellebrandt <lhellebr>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 570CC: eherget, lhellebr, tlestach
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rhncfg-5.10.87-8-sat Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-21 12:11:37 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:    
Bug Blocks: 1358815    
Attachments:
Description Flags
Helper script creating the config channel and managed file on the satellite 5 server
none
Main script presenting the issue. none

Description Radovan Drazny 2016-07-28 16:22:04 UTC
Created attachment 1185181 [details]
Helper script creating the config channel and managed file on the satellite 5 server

Description of problem:
Under certain conditions, rhncfg-client can overwrite local file that is not managed by Satellite 5 config management. 

Version-Release number of selected component (if applicable):
rhncfg-client-5.10.74-11.el7sat

How reproducible:
always

Steps to Reproduce:
Bug is triggered only under following condition:
rhncfg-client backup directory (/var/lib/rhncfg/backups by default) MUST be on a different filesystem than the file managed by the rhncfg-client.

1. On a client registered to a Satellite 5 server create a local file in a location on a different filesystem than the rhncfg-client backup directory.
2. Create a symlink pointing to the local file from step 1. This symlink must be on different filesystem than the rhncfg-client backup directory.
3. Create a configuration channel on the Satellite 5 server, containing a managed configuration file with the same path as the symlink created in step 2. Subscribe the client from step 1 to this configuration channel and enable the config management on this client.
4. Run "rhncfg-client get" on the client. Symlink will be backed up to the backup dir, and replaced with the managed file from step 3. 
5. Run "rhncfg-client get" again. Expected behavior is that file deployed in step 4 will get backed up, replacing the original backed up symlink. Instead, the symlink remains in the backup directory, and symlink target is overwritten by the backup. 

Actual results:
Symlink backup isn't replaced by the file backup, the original symlink target is overwritten instead.

Expected results:
Symlink backup is replaced by the file backup, original symlink target remains untouched.

Additional info:
Problem is in file /usr/share/rhn/config_common/transactions.py on lines 87-106. This code path is triggered by "OSError: [Errno 18] Invalid cross-device link" exception on line 87, which occurs only when backup dir lies on different filesystem than the original file. If both managed file/original symlink and backup directory are on the same filesystem, backup works as expected, and symlink target doesn't get overwritten. 

I have attached reproducer script to illustrate the problem. Place both files to same directory, make runtest.sh executable and run it on a client registered to a Satellite server with following parameters:

runtest.sh http://<satellite_server_domainname> <sat_username> <sat_password>

The script creates all files and filesystem in the /tmp directory, and config channel and managed file on the Satellite 5 server specified on the command line.

Comment 1 Radovan Drazny 2016-07-28 16:22:52 UTC
Created attachment 1185182 [details]
Main script presenting the issue.

Comment 2 Eric Herget 2017-02-22 21:32:40 UTC
spacewalk.github:
9bacb8c9ece1c385549da9267b7b9ec39bb607e9

rhncfg-5.10.102-1

Comment 4 Lukáš Hellebrandt 2017-04-19 09:45:19 UTC
Verified with rhncfg-5.10.87-9 against Sat5.8.

Used rdrazny's reproducer. The managed file contains "MANAGED", the backup file contains "MANAGED" (and is NOT a symlink) and the linked file contains "LOCAL".