Proper setting of %ghost file spec section in order to rpm -V to be silent wrt to mode differs ('M') change - handling db & log files

[Vít Ondruch]

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=5ca32d2c71cc1bb9225ab8a25fdae3d522ae4202


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