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.