Bug 813571 - rpm -V fails for pulp gofer python-gofer
rpm -V fails for pulp gofer python-gofer
Status: CLOSED UPSTREAM
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Content Management (Show other bugs)
6.0.1
Unspecified Unspecified
medium Severity medium (vote)
: Unspecified
: 6.0
Assigned To: Jeff Ortel
Katello QA List
: Triaged
: 813941 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-17 18:17 EDT by Chandrasekar Kannan
Modified: 2015-01-04 18:51 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-19 14:11:56 EDT
Type: Bug
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 Chandrasekar Kannan 2012-04-17 18:17:21 EDT
rpm verification test fails.


rpm -V pulp gofer python-gofer

python-gofer.noarch: /var/lib/gofer/journal/watchdog .M.......  [tps:B]
pulp.noarch: /etc/pki/pulp/consumer .....UG..  [tps:B]
gofer.noarch: /var/log/gofer .M.......  [tps:B]
Comment 1 Lukas Zapletal 2012-04-18 04:17:45 EDT
Yeah, we have more. Definitely nice to have, we should put RPM -V checkup onto our scrum. I'd recommend to change component to Katello and push this upstream only.
Comment 3 James Laska 2012-04-18 08:14:02 EDT
I've discussed this failure already with jortel.  The alternative is to adjust the %postinstall script (removing the setfacl) and use the proper .spec syntax in %files.  However, this causes rpmlint to fail.

> 09:09 jortel: now I remember why I used setfacl instead of %attr, see: http://fpaste.org/x6F9/
> 09:10 jortel: setfacl "get around" these lint errors

Pick your poison.  I'm more comfortable with the verify error, than I am with rpmlint failures.  Any other thoughts?
Comment 4 Justin Sherrill 2012-04-18 11:20:46 EDT
From a support perspective, it is very very common to examine the output of rpm -V to detect causes of errors in a product.  That said it is not uncommon to have a set of files that you ignore because they always show up.  So while I'm not arguing for the going with the rpm lint error, it is one more 'exception' support will have to remember when supporting the product. 

One question i guess is does that directory NEED to be world writable ?  As that seems kinda bad.
Comment 5 Brian Hamrick 2012-04-18 15:19:56 EDT
Gathering rpm -V output is turned off by default for sosreport in RHEL 6, so this should not be a big deal.  Even if someone turns it on to collect -Va output, as this will just report an error for this package it should not be a show-stopper.

As long as we document this issue before it is fixed we should be fine.
Comment 6 Eric Sammons 2012-04-19 11:17:59 EDT
*** Bug 813941 has been marked as a duplicate of this bug. ***
Comment 8 Justin Sherrill 2012-04-19 11:42:55 EDT
So i see it as this:

1.  The rpm requires a world writable directory
2.  rpm lint complains about this because world writable directories are bad
3.  We hacked around this to hush rpmlint (pushing the permission setting to %postinstall)
4.  Because we hacked around this rpm -V throws a warning.


I would argue that we shouldn't hack around this (step 3 is a mistake).  We are essentially ignoring what rpmlint is saying by making sure rpmlint can't see that we are making the rpm world writable which is BAD imho.  

Talking with jortel this should be fixed in a future version of gofer.  So to me rpmlint should complain until we upgrade to that version.
Comment 9 Justin Sherrill 2012-04-19 12:11:03 EDT
So i would argue that if its a blocker that rpmlint it throwing an error, then it is a blocker that we need to move to a newer version of gopher that does not require a world writable directory.
Comment 10 Eric Sammons 2012-04-19 13:57:19 EDT
rpmlint is not customer facing so I would say that we have two choices.

1. Let rpmlint complain (thus rpm -V will not).
2. Update to a more secure version of gofer.

And what of the pulp issue where the UG are changing?
Comment 11 Lukas Zapletal 2012-04-20 08:00:12 EDT
FYI Katello passes this test with only one exception. We "hack" seeds.rb script. Not sure if /var/log/katello is also right (we change permissions there using Puppet).

# rpm -V katello katello-common katello-cli katello-certs-tools katello-selinux katello-all katello-configure
..5....T.    /usr/share/katello/db/seeds.rb
SM5..UGT.  c /etc/httpd/conf.d/katello.conf
S.5..UGT.  c /etc/katello/katello.yml
S.5....T.  c /etc/katello/thin.yml
S.5....T.  c /etc/sysconfig/katello
.M.......    /var/log/katello
Comment 12 Eric Sammons 2012-04-20 13:34:49 EDT
The primary offenders here are pulp, python-gofer and gofer.
Comment 15 Jeff Ortel 2012-08-07 17:36:13 EDT
Fixed in gofer around 0.68.
Tested with gofer 0.71 installed.  'rpm -V gofer python-gofer' reported not issues.
Comment 17 Mike McCune 2013-08-16 14:02:32 EDT
getting rid of 6.0.0 version since that doesn't exist
Comment 18 Mike McCune 2013-09-19 14:11:56 EDT
These bugs have been resolved in upstream projects for a period of months so I'm mass-closing them as CLOSED:UPSTREAM.  If this is a mistake feel free to re-open.

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