Bug 857930

Summary: Directory /var/log/puppet is world readable
Product: [Fedora] Fedora EPEL Reporter: Lukas Zapletal <lzap>
Component: puppetAssignee: Todd Zullinger <tmz>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: el6CC: k.georgiou, kseifried, ktdreyer, msuchy, tmz, vanmeeuwen+fedora, wnefal+redhatbugzilla
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-18 14:12:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Lukas Zapletal 2012-09-17 14:14:02 UTC
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 20:39:07 UTC
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-18 00:44:28 UTC
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 08:56:26 UTC
Thanks Todd. Are you going to push the fix for epel6?

Comment 4 Miroslav Suchý 2012-09-18 09:06:42 UTC
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 13:38:52 UTC
(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 14:12:27 UTC
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).