Milos suggests running restorecon after touch.

But we have to change the policy accordingly. If the file has a correct label and the 'unconfined' module is disabled, then it will be impossible to remove the lock file.

# sesearch -s system_cronjob_t -t system_cronjob_lock_t -c file -p unlink -A -C
Found 2 semantic av rules:
   allow files_unconfined_type file_type : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint open } ; 
   allow system_cronjob_t system_cronjob_lock_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 

# sesearch -s system_cronjob_t -t var_lock_t -c file -p unlink -A -C
Found 1 semantic av rules:
   allow files_unconfined_type file_type : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint open } ; 

# rpm -qa selinux\*
selinux-policy-3.7.19-260.el6.noarch
selinux-policy-minimum-3.7.19-260.el6.noarch
selinux-policy-doc-3.7.19-260.el6.noarch
selinux-policy-targeted-3.7.19-260.el6.noarch
selinux-policy-mls-3.7.19-260.el6.noarch

This is only selinux issue, right? There is only "touch Makefile" and "touch /var/cache/man/whatis. No touch for makewhatis.cron.

Only:
install -m755 %{SOURCE2} $RPM_BUILD_ROOT/etc/cron.daily/makewhatis.cron

This looks to me as a cron bug, not man one. What do you think?

# grep LOCKFILE /etc/cron.daily/makewhatis.cron 
LOCKFILE=/var/lock/makewhatis.lock
[ -f $LOCKFILE ] && exit 0
trap "{ rm -f $LOCKFILE ; exit 255; }" EXIT
touch $LOCKFILE
#

...which means that a proper way to fix /etc/cron.daily/makewhatis.cron is:

touch $LOCKFILE; restorecon $LOCKFILE

The other part of the issue is in the selinux policy. But they know what to do.

There was a needinfo on me so I answered with this summary.

Ok, This is probably also SELinux bug. We have

matchpathcon /var/lock/makewhatis.lock
/var/lock/makewhatis.lock	<<none>>

on RHEL7 but we have

[mgrepl@rhel6 ~]$ matchpathcon /var/lock/makewhatis.lock
/var/lock/makewhatis.lock	system_u:object_r:var_lock_t:s0

on RHEL6. It makes sense to don't have a default label for lock files created on the fly.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0645.html