It would be nice if you could refer to specific SRPM.
Nevertheless, by coincidence, I was playing with something similar today
and I ended up with this patch:
http://pkgs.fedoraproject.org/cgit/rubygem-bundler.git/commit/?id=5ca32d2...
I.e. if the file is present on the file system, the permissions are
taken from the file. If the file is not present, there are no
permissions set and rpmlint complains about it:
rubygem-bundler.noarch: E: non-readable
/usr/share/gems/gems/bundler-1.7.8/lib/bundler/vendor/thor 0L
The file can't be read by everybody. Review if this is expected.
To fix this problem, you should use the %attr directive:
%ghost %attr(644, root, root) %{gem_libdir}/bundler/vendor/thor
In this case, the file have associated permissions. And these files are
always listed by RPM of course, no matter if they have set permissions
or not:
$ rpm -ql -p
/var/lib/mock/fedora-rawhide-x86_64/result/rubygem-bundler-1.7.8-2.fc22.noarch.rpm
| grep thor\$
/usr/share/gems/gems/bundler-1.7.8/lib/bundler/vendor/thor
I can't see any issues with rpm -V:
# rpm -q rubygem-bundler
rubygem-bundler-1.7.8-2.fc22.noarch
# rpm -V rubygem-bundler
# echo $?
0
Vít
Dne 5.2.2015 v 15:36 Jan Lieskovsky napsal(a):
Hello folks,
(apologize for the wide distribution, hopefully someone would be able
to help me with the issue below).
we develop a tool performing security scans / audits of the system. This tool
is able to compare the system in question against various rules. And one of these
rules ('Verify and Correct File Permissions with RPM') fails on common (RHEL-6)
system.
When inspecting the failure more deeply noticed all these files are marked as
%ghost files in particular *.spec file. The test is failing due to changed group
ownership & mode on these files.
Having look at:
[1]
http://fedoraproject.org/wiki/PackagingDrafts/Logfiles
suggests it should be possible to define particular *.spec %ghost section that way,
so rpm -V would be silent (at least wrt to 'md5', 'size' &
'mtime' attributes).
Since the files marked as %ghost are kinda special:
[2]
http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html
wondering if it's even possible to classify the %ghost file in particular *.spec
file that way, so rpm -V wrt to group ownership & mode changes would be silent.
If I got the %ghost directive meaning [2] correctly:
* RPM knows about the ghosted file (it's saved into RPM db),
* but it will not add it to the package (but in the moment of build
that file needs to be present in the buildroot),
* that file will be marked as owned by the package, and will be
removed when the package is removed,
* that file won't be visible from package file's listing (rpm -ql),
* [2] also mentions it's possible to use 'rpm --setperms' on the ghosted
file to fix it permissions.
The question:
Suppose 'rpm -V' reports group ownership change & mode change failure. The
question is how to write the corresponding *.spec %ghost section this not
to be reported?
Use something like:?
%ghost %verify(not group mode md5 size mtime} file_path
Wouldn't this tell RPM that if there's change in some of group / mode / md5 /
size / mtime
attribute of that file, that this change should be ignored?
Or instead of blessing the attribute like above, it's better to get the:
* expected group owner & mode for that %ghost file from RPM db,
* and in the moment of creating that file call 'chgrp / chmod' with
the expected values?
For case someone would be interested in data wrt to these failing files, those
are mainly db / SQLite / log or pid files. Some examples:
* /var/log/gdm
* /var/run/gdm
* /var/run/abrt.pid
* /var/lib/rpm/__db.*
* /var/lib/mlocate/mlocate.db
* /var/lib/PackageKit/transactions.db
* .. etc etc
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team