Bug 587285

Summary: RFE: Event history should be more precise with SELinux problems
Product: [Community] Spacewalk Reporter: Sandro Mathys <sandro>
Component: WebUIAssignee: Justin Sherrill <jsherril>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: medium Docs Contact:
Priority: low    
Version: 0.8CC: jpazdziora, roysjosh
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-19 16:17:10 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: 623772    

Description Sandro Mathys 2010-04-29 14:19:58 UTC
If you try to deploy a config file with a non-existing/wrong SELinux context the event history will simply say 'invalid argument' leaving the administrator with a big question mark. It should instead say something like "file /path/to/foobar could not be deployed because of invalid SELinux context".

Comment 1 Sandro Mathys 2010-04-29 14:30:59 UTC
By the way, let me post the error messages. Client is a Fedora 13 Beta.

Spacewalk WebUI:
Failed deployment, rolled back: [Errno 22] Invalid argument (code 49)

Client's /var/log/rhncfg-actions (with debug=10):
2010-04-29 16:21:10 transactions.deploy: deploying transaction
2010-04-29 16:21:10 transactions.deploy: directory not found, creating: /nas
2010-04-29 16:21:10 utils.mkdir_p: testing /nas
2010-04-29 16:21:10 utils.mkdir_p: created /nas
2010-04-29 16:21:10 utils.mkdir_p: dirs_created: ['/nas']
2010-04-29 16:21:10 transactions.deploy: changed_dir_info: {}
2010-04-29 16:21:10 transactions.deploy: new_dirs: ['/nas']
2010-04-29 16:21:10 transactions.deploy: done with directory creation, moving on to files
2010-04-29 16:21:10 transactions.deploy: writing new version of /etc/modprobe.d/no-ipv6 to tmp file ...
2010-04-29 16:21:10 transactions._chown_chmod_chcon: selinux context: user_u:object_r:user_home_t
2010-04-29 16:21:10 transactions.rollback: rolling back
2010-04-29 16:21:10 transactions.rollback: removing tmp file /etc/modprobe.d/.rhn-cfg-tmp-3129-sm9wp3 ...
2010-04-29 16:21:10 transactions.rollback: tmp file removed
2010-04-29 16:21:10 transactions.rollback: removing directory /nas that was created during transaction ...
2010-04-29 16:21:10 transactions.rollback: directory removed
2010-04-29 16:21:10 transactions.rollback: rollback successful
2010-04-29 16:21:10 configfiles.deploy: Failed deployment, rolled back: [Errno 22] Invalid argument

---

All our files seem to have had the SELinux context user_u:object_r:user_home_t and I wouldn't know why one of us would set them to that because it's all system files (like for pam/ldap/access/nsswitch/...) so I wonder if that's a default (which IMHO should be empty). Maybe it came from uploading the fiels with rhncfg-manager from a backup which was in a users home tho...that'd explain the contexts I guess.

Comment 2 Sandro Mathys 2010-04-29 17:11:48 UTC
Okay, after applying the patch from Joshua Roys I now get the following message instead which is really helpful:

"Failed deployment, rolled back: ('failed to set selinux context on /etc/nsswitch.conf', OSError(22, 'Invalid argument'))" (code 49)

Thanks a lot for the fast and very good patch Joshua!

cae64f15933666eca92edaa3dad2d00f22954113

Comment 3 Jan Pazdziora (Red Hat) 2010-04-30 08:11:51 UTC
Let's call this bugzilla MODIFIED, as the fix is in Spacewalk git master but was not tagged and built yet.

Comment 4 Jan Pazdziora (Red Hat) 2010-10-27 08:32:48 UTC
Mass-aligning under space12, so that we don't lose track of this bugzilla. This however does not mean that we plan (will be able to) address this bug in Spacewalk 1.2.

Comment 6 Jan Pazdziora (Red Hat) 2010-11-19 16:17:10 UTC
With Spacewalk 1.2 released, marking as CLOSED CURRENTRELEASE.

https://www.redhat.com/archives/spacewalk-list/2010-November/msg00111.html