Bug 689770

Summary: rhncfg-manager not able to deploy files with owner/group unknown to system
Product: Red Hat Satellite 5 Reporter: Andreas Bleischwitz <ableisch>
Component: Configuration ManagementAssignee: Tomas Lestach <tlestach>
Status: CLOSED DUPLICATE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: high Docs Contact:
Priority: medium    
Version: 540CC: clasohm, cperry, goetz.dirk, pmutha, slukasik, stephan.duehr
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-22 20:49:40 UTC Type: ---
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: 677498    

Description Andreas Bleischwitz 2011-03-22 12:08:51 UTC
Description of problem:
Trying to "download-channel" using rhncfg-manager fails if the owner/group of a configfile is unknown to the system. Susequent files are not deployed.

Version-Release number of selected component (if applicable):
rhncfg-5.9.27-1.el5sat

How reproducible:

Steps to Reproduce:
1. create a configfile owned by a user unknown to the system.
2. try to download this file using "rhncfg-manager download-channel"
3.
  
Actual results:
Python stack-trace:
....
  File "/usr/share/rhn/config_common/utils.py", line 248, in set_file_info
    uid = pwd.getpwnam(finfo['username])[2]
KeyError: 'getpwnam(): name not found: xxxx'


Expected results:
A warning should be displayed, uid/gid should be set to root.

Additional info:

Comment 1 Andreas Bleischwitz 2011-04-28 08:06:37 UTC
Found another position of this BUG:

/usr/share/rhn/config_common/transactions.py (122 + 136)

Comment 3 Tomas Lestach 2011-06-21 09:43:04 UTC
This might be a security issue.

I do not recommend switching file owner/group to root in case the user isn't present in the system.

Nowadays a UserNotFound exception is raised, what I mean is a correct behavior.

Comment 4 Clifford Perry 2011-06-22 20:49:40 UTC

*** This bug has been marked as a duplicate of bug 479087 ***