Description of problem: I noticed, that inside of /var/satellite/redhat/1/ lots of folders belong to root:root instead of apache:apache, which will e.g. raise a problem with rhnpush. I didn't have the time to deeply investigate into this. Not all folders belong to root:root, some have correct ownership. Version-Release number of selected component (if applicable): # rpm -qa | grep spacewalk spacewalk-search-0.6.11-1.el5 spacewalk-branding-0.6.8-1.el5 spacewalk-0.6.4-1.el5 spacewalk-html-0.6.19-1.el5 spacewalk-backend-0.6.30-1.el5 spacewalk-backend-config-files-0.6.30-1.el5 spacewalk-taskomatic-0.6.42-1.el5 spacewalk-schema-0.6.22-1.el5 rhn-org-httpd-ssl-key-pair-spacewalk-1.0-4 spacewalk-backend-xml-export-libs-0.6.30-1.el5 spacewalk-backend-package-push-server-0.6.30-1.el5 spacewalk-moon-0.6.19-1.el5 spacewalk-client-tools-0.0-1 spacewalk-java-config-0.6.42-1.el5 spacewalk-monitoring-0.6.7-1.el5 spacewalk-admin-0.6.3-1.el5 spacewalk-backend-server-0.6.30-1.el5 spacewalk-backend-app-0.6.30-1.el5 spacewalk-backend-iss-export-0.6.30-1.el5 spacewalk-backend-xp-0.6.30-1.el5 spacewalk-pxt-0.6.19-1.el5 spacewalk-cypress-0.6.19-1.el5 spacewalk-selinux-0.6.13-1.el5 spacewalk-java-lib-0.6.42-1.el5 spacewalk-backend-sql-0.6.30-1.el5 spacewalk-backend-xmlrpc-0.6.30-1.el5 spacewalk-backend-config-files-tool-0.6.30-1.el5 spacewalk-backend-iss-0.6.30-1.el5 spacewalk-base-0.6.19-1.el5 spacewalk-sniglets-0.6.19-1.el5 spacewalk-certs-tools-0.6.3-1.el5 spacewalk-doc-indexes-0.6.1-1.el5 spacewalk-config-0.6.13-1.el5 spacewalk-base-minimal-0.6.19-1.el5 spacewalk-backend-config-files-common-0.6.30-1.el5 spacewalk-backend-applet-0.6.30-1.el5 spacewalk-grail-0.6.19-1.el5 spacewalk-monitoring-selinux-0.6.12-1.el5 spacewalk-backend-tools-0.6.30-1.el5 spacewalk-java-0.6.42-1.el5 spacewalk-setup-0.6.21-1.el5 How reproducible: no idea Steps to Reproduce: no idea Actual results: /var/satellite/redhat/1/* party belongs to root:root Expected results: /var/satellite/redhat/1/* should belong to apache:apache Additional info: I only used spacewalk-repo-sync before, i.e. didn't upload pkgs through any different way (like rhnpush). I see this behaviour on two separate test-installations of spacewalk 0.6, one was a 0.5 and then upgraded, the other was post-0.5-nightly (about 2 weeks ago) and then upgraded.
This has been confirmed as being spacewalk-repo-sync's fault by other users. I dived a bit into that python stuff and made the following patch, which works for me. Be aware, that this was made by a person who's missing the understanding of the whole backend. My change might influence other scripts in a bad way. --- /usr/share/rhn/server/rhnPackageUpload.py.orig 2009-08-15 19:57:34.000000000 +0200 +++ /usr/share/rhn/server/rhnPackageUpload.py 2009-08-15 20:11:57.000000000 +0200 @@ -147,6 +147,8 @@ except importLib.FileConflictError: raise rhnFault(50, "File already exists") + os.system("chown apache:apache %s/%s" % (CFG.MOUNT_POINT, relative_path)) + pkg = mpmSource.create_package(header, size=payload_size, md5sum=md5sum, relpath=relative_path, org_id=org_id, header_start=header_start, header_end=header_end, channels=channels)
Okay I have reproduced this on 0.6 and 0.7 so here's some steps: 1) Spacewalk install that is empty of any packages so that /var/satellite/redhat/{$org_number}/ is empty. Verify that that directory is owned by apache:apache as it should be by default. 2) Create a channel and rhnpush something to it. 3) Verify that the directory created for this within /var/satellite/redhat/{$org_number}/ is owned by apache:apache as it should be. 2) Create a channel and sync it with an upstream yum repository with the spacewalk-repo-sync python command/script. 3) Check the ownership of the folders within /var/satellite/redhat/${org_number}/ directory. They will be shown as root:root apart from the directory created earlier by the rhnpush command which will be apache:apache properly. 4) rhnpush something that would end up in one of the directories that had been automatically created by spacewalk-repo-sync 5) the rhnpush will fail with permission denied to /var/satellite/redhat/{$org_number}/{something}/ 6) chown apache:apache the directory mentioned in the error and try to rhnpush again - this time it will be successful. Suggestion for fix: Have a configurable value in /etc/rhn/rhn.conf or /etc/sysconfig/up2date defaulting to apache for the owner/group the spacewalk server is running the web interface as. Have spacewalk-repo-sync drop credentials when run or otherwise fork itself to a process run as the user configured for the web interface. I don't believe there is anything that spacewalk-repo-sync specifically needs to be root for during the sync? If not then dropping credentials would be fine.... If it does then either chown each package and directory after import or fork the bit that creates the folders and file to the user would work...
Rather than chowning the directory in rhnPackageUpload.py the actual direcory creation and file write is carried out by server/importlib/importLib.py It would be better to have that read in the configuration for what user the directory path and files should be and write out as that user. Specifically the copy_package method defined appears to be responsible for the final actual directory creation and file write so an os.chown would probably be better there...
*** Bug 527990 has been marked as a duplicate of this bug. ***
Fixed in spacewalk.git: commit fd48c14fa88f53c59ea117e235f93c7010fc79a3 516767 - create files with default repository owner/group/permissions rather than root.root Fixed package: spacewalk-backend-0.8.5-1
Spacewalk 0.8 has been released
Also reported: Bug 567649 - rhnpush creates apache:apache files/dirs in /var/satellite/redhat/1/