Bug 467189 - rhncfg-manager download-channel does not set the correct permissions
rhncfg-manager download-channel does not set the correct permissions
Status: CLOSED CURRENTRELEASE
Product: Spacewalk
Classification: Community
Component: Clients (Show other bugs)
0.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Mráka
Red Hat Satellite QA List
:
Depends On:
Blocks: space03
  Show dependency treegraph
 
Reported: 2008-10-16 06:01 EDT by Michael Mráka
Modified: 2009-09-17 03:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-17 03:02:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Mráka 2008-10-16 06:01:15 EDT
+++ This bug was initially created as a clone of Bug #428721 +++

Description of problem:
When using rhncfg-manager download-channel to download a configuration channel, the tool does not set the permissions on the downloaded files correctly to the settings entered through the satellite interface. 

How reproducible:
Always

Steps to Reproduce:

Create a config channel (config-channel-name) and upload config files/create config file and under File Permissions Mode *: give anything apart from 644. Example - give 642

Then subscribe the system to this config channel.

On client system -
- go to a temporary directory 
# cd /tmp 

- use rhncfg-manager to download the required channel, specifying the temporary directory 
 
# rhncfg-manager download-channel --topdir /tmp config-channel-name

- check the ownership and file permissions on the files downloaded 
 
ls -al  /tmp/config-channel-name
# ls -al /tmp/139616-Config/*

The files downloaded are having the permissions as 644 and not the ones specified on Satellite (642).


Actual results:
File permissions after download are 644

Expected results:
It should have been as the one specified under the config channel - 642

--- Engineering ---

It seems that we simply ignore the "mode" set from the WebUI while
downloading the config files. So, when these files get downloaded it uses
the default umask which sets the permissions to 644 for a file.

rhncfg_download_channel.py:

for file_path in r.list_files(ns):
   #5/11/05 wregglej - 157066 dirs_created now gets returned by
get_file_info.
   (temp_file, info, dirs_created) = r.get_file_info(ns, file_path)
   dest_file = utils.join_path(topdir, ns, file_path)
   print "Deploying %s -> %s" % (file_path, dest_file)
   utils.copyfile_p(temp_file, dest_file)	-> This is where the file gets
copied to the destination.

get_file_info() - Returns all the attributes related to the configuration
file including the 'filemode'.

so looking at utils.copyfile_p():

def copyfile_p(src, dst):
    """
    Simple util function, copies src path to dst path, making
    directories as necessary. File permissions are not preserved.
    """
.
.
.
if os.path.isdir(src):
        if not os.path.exists(dst):
            os.mkdir(dst)
    else:
        shutil.copy(src, dst)

copy(src, dst) - Copy data and mode bits ("cp src dst"). 

This is a simple copy, I tried using copy2() but that does help.

copy2(src, dst) - Copy data and all stat info ("cp -p src dst")

Probably, we'll have to somehow make the "mode" available to this
function, this issue is only while downloading the file using
rhncfg-manager, deploying config files take care of the mode set from the
webui.
Comment 1 Michael Mráka 2008-10-16 06:58:39 EDT
Fixed in git repo.
Created commit a4ec562: 467189, 428721 - set filemode and ownership on config files
 2 files changed, 9 insertions(+), 0 deletions(-)
Comment 2 Michael Mráka 2008-10-16 07:16:59 EDT
Oops :), the right commit sha1 is
commit fb7b883ed63412c834d72af27b9ff46ed00b076a
    467189, 428721 - set filemode and ownership on config files
Comment 5 Miroslav Suchý 2009-09-17 03:02:05 EDT
Spacewalk has been released for some time.

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