This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 857930 - Directory /var/log/puppet is world readable
Directory /var/log/puppet is world readable
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: puppet (Show other bugs)
el6
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Todd Zullinger
Fedora Extras Quality Assurance
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-17 10:14 EDT by Lukas Zapletal
Modified: 2013-03-18 10:12 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-18 10:12:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lukas Zapletal 2012-09-17 10:14:02 EDT
Description of problem:

/var/log/puppet is world readable and may contain sensitive information

Also the files contained within are world readable.

Version-Release number of selected component (if applicable):

puppet-2.6.14-1.el6.noarch
puppet-2.6.17-2.el6.noarch

How reproducible:

drwxr-xr-x.  2 puppet        puppet          4096 Mar  8 16:35 /var/log/puppet

This bug seems to be fixed in Fedora.
Comment 1 Todd Zullinger 2012-09-17 16:39:07 EDT
Something is wrong here.  The spec file creates the dir as 750 and specifies that in the attr section of %files.

%attr(0750, puppet, puppet) %{_localstatedir}/log/puppet

This is a bug that was supposed to be resolved a while ago (in fact, twice, according to the changelog).  I'll have to do some test builds to see what's going wrong here.

Both el5 and el6 (as well as fedora 16) are built from identical srpms.  This seems like it could be a bug in el6 rpm or at least something different in how it parses the spec file's %attr().
Comment 2 Todd Zullinger 2012-09-17 20:44:28 EDT
Indeed this looks like it might be something wrong with rpm on el6.  I ran scratch builds from the el6 branch for el5 and el6.  The el6 branch has the wrong permissions.  The %defattr(-, 'root', 'root', 0755) is overriding the %attr line.  I changed 0755 to - and the log dir retains the proper permissions.  Same result if %defattr is completely removed, as both Fedora and EL6+ support.  So the simple solution is to just take advantage of the fact that %defattr is no longer required on those systems.
Comment 3 Lukas Zapletal 2012-09-18 04:56:26 EDT
Thanks Todd. Are you going to push the fix for epel6?
Comment 4 Miroslav Suchý 2012-09-18 05:06:42 EDT
The problem is that %attr only specify file mode, IMHO not directories.
You either should do:
  %defattr(-, root, root, -)
or even completly remove it (and leave it only for el5. Because this is default value.
If you need to specify attributes on directories, you can do that by 
  chmod 750  %{buildroot}%{_localstatedir}/log/puppet
at the end of %install section.
Comment 5 Todd Zullinger 2012-09-18 09:38:52 EDT
(In reply to comment #4)
> The problem is that %attr only specify file mode, IMHO not directories.
> You either should do:
>   %defattr(-, root, root, -)
> or even completly remove it (and leave it only for el5. Because this is
> default value.

Right. My plan is to simply remove %defattr on all but el5 (as well as dropping %clean and rm %{buildroot} in %install on fedora and el6+).

> If you need to specify attributes on directories, you can do that by 
>   chmod 750  %{buildroot}%{_localstatedir}/log/puppet
> at the end of %install section.

This is not true in my testing.  We have long set the mode in the %install section and this did not suffice in any of the releases, as I did this way back when a bug was first filed on this.  Only after finding that was not enough did I add the %attr, which worked in Fedora and EPEL, and still works in Fedora and EPEL-5, as the perms there are correct using both %defattr and %attr.

It is an unfortunate behavior change in rpm for el6 as far as I am concerned.  But that's not a bug I'm going to chase down.
Comment 6 Todd Zullinger 2013-03-18 10:12:27 EDT
This is resolved with the recent build of 2.6.18-1.el6.  That confirms my belief that this was a bug in rpm (or the build system).

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