Bug 512275

An alternative workaround might be to have the hmaccalc package create /etc/prelink.conf.d/hmaccalc.conf blacklisting prelinking of the necessary components.

I think it's as simple as the 'prelink' command not being in $PATH, so the trick of asking it to output the unprelinked (original) version and running the self-check over that doesn't work right.  Can you confirm whether or not
  PATH="$PATH":/usr/sbin sha512hmac /dev/null
works around it on a prelinked system?  (It does on mine, but I'd like to be sure.)

(In reply to comment #2)
> I think it's as simple as the 'prelink' command not being in $PATH, so the
> trick of asking it to output the unprelinked (original) version and running the
> self-check over that doesn't work right.  Can you confirm whether or not
>   PATH="$PATH":/usr/sbin sha512hmac /dev/null
> works around it on a prelinked system?  (It does on mine, but I'd like to be
> sure.)  

Yes, confirmed, you are indeed correct. Adding /usr/sbin to the users PATH causes the self test to no longer fail.

Likewise, creating a symlink to prelink in /usr/bin (or anywhere on the users PATH) also provides a workaround.

Personally I'd favour prelink blacklisting over having /usr/sbin or to a lesser extent prelink in a (non-root) users PATH, not to imply you were suggesting that as a solution.

I also think that adding /usr/bin/sha512hmac to the prelink blacklist is a reasonable solution.  If a non-root user cannot run sha512hmac without first applying a workaround, that would cause some cries down the road:

$ sha512hmac /bin/ls
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)

(In reply to comment #3)
> Personally I'd favour prelink blacklisting over having /usr/sbin or to a lesser
> extent prelink in a (non-root) users PATH, not to imply you were suggesting
> that as a solution.  

My suggested solution is to check for the exact path to the prelink command at build-time, and to attempt to invoke it directly using the full path whenever we need an unprelinked version of something, falling back to the current behavior of attempting to start it using $PATH.  I'm not wedded to it, but it works out to a rather straightforward change.

(In reply to comment #5)
> (In reply to comment #3)
> > Personally I'd favour prelink blacklisting over having /usr/sbin or to a lesser
> > extent prelink in a (non-root) users PATH, not to imply you were suggesting
> > that as a solution.  
> 
> My suggested solution is to check for the exact path to the prelink command at
> build-time, and to attempt to invoke it directly using the full path whenever
> we need an unprelinked version of something, falling back to the current
> behavior of attempting to start it using $PATH.  I'm not wedded to it, but it
> works out to a rather straightforward change.  

It is now coming up to two months since this problem was first identified.

Is there any movement on providing the above mentioned simple fix, please?

The suggested fix was added to the upstream tree in 0.9.9, and it is being considered for inclusion in an update.

(In reply to comment #8)
> The suggested fix was added to the upstream tree in 0.9.9, and it is being
> considered for inclusion in an update.  

That is good news. Thank you for the information update.

It is always nice to know the status of a reported issue. :-)

Just an addition here, I'm used to do "su" and not "su -":

[root@napanee patchwork]# sha512hmac /etc/passwd
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)
[root@napanee patchwork]# su -
[root@napanee ~]# sha512hmac /etc/passwd
71ea01dd284be482b864cd90a2b8520e92e95bef69400c68557d54f649c78d82a415499606115927e43029b81cc6338aaff2a026f2b796ac4dc214101804583a  /etc/passwd
[root@napanee ~]#

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0055.html

The workaround for hmaccalc-0.9.6-3.el5 (hmaccalc-prelink-path.patch) does not work is partition is mounted noexec.

I'm trying to compile the kernel and rpmbuild fail on:

pushd $RPM_BUILD_ROOT &&
%_hmacdir/sha512hmac %{image_install_path}/vmlinuz-$KernelVer > \
    %{image_install_path}/.vmlinuz-$KernelVer.hmac && popd

because /tmp and /var/tmp are mounted noexec:

+ echo 'Creating hmac file: /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root/boot/.vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM.hmac'
Creating hmac file: /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root/boot/.vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM.hmac
+ pushd /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root
/var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root ~/work/rpm/BUILD/kernel-2.6.18/linux-2.6.18.x86_64
+ /usr/bin/sha512hmac boot/vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)

(In reply to comment #16)
> The workaround for hmaccalc-0.9.6-3.el5 (hmaccalc-prelink-path.patch) does not
> work is partition is mounted noexec.

That wasn't really the problem it was addressing -- the hmaccalc command had previously assumed that the "prelink" command could be found somewhere in the $PATH, which is incorrect.  If the binary had been prelinked after installation, hmaccalc wouldn't be able to ask prelink to give it a copy of itself as it had looked before prelinking against which to verify its checksum.

> I'm trying to compile the kernel and rpmbuild fail on:
> 
> pushd $RPM_BUILD_ROOT &&
> %_hmacdir/sha512hmac %{image_install_path}/vmlinuz-$KernelVer > \
>     %{image_install_path}/.vmlinuz-$KernelVer.hmac && popd
> 
> because /tmp and /var/tmp are mounted noexec:
> 
> + echo 'Creating hmac file:
> /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root/boot/.vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM.hmac'
> Creating hmac file:
> /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root/boot/.vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM.hmac
> + pushd /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root
> /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root
> ~/work/rpm/BUILD/kernel-2.6.18/linux-2.6.18.x86_64
> + /usr/bin/sha512hmac boot/vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM
> SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)    

It's a little hard to read the output, but I'm not seeing the .spec file attempting to execute anything in /var/tmp or /tmp here.

When you run the command directly, does it still fail?  Can you run it under 'strace -f -s 128' and attach the output?

(In reply to comment #17)
> It's a little hard to read the output, but I'm not seeing the .spec file
> attempting to execute anything in /var/tmp or /tmp here.
Yes it is.
- kernel-2.6.18-164.15.1.el5.src.rpm
- kernel-2.6.spec line 9118
$RPM_BUILD_ROOT is expanded to /var/tmp/kernel-2.6.18-164.15.1.el5-root

# pushd /var/tmp
/var/tmp ~
# mount | grep tmp
/dev/sdb6 on /tmp type xfs (rw,noexec,nosuid,nodev)
tmpfs on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
/tmp on /var/tmp type none (rw,noexec,nosuid,nodev,bind)
# cp /bin/ls .
# /usr/bin/sha512hmac ls
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)
# strace -f -s 128 -o ~/sha512hmac.log /usr/bin/sha512hmac ls
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)
# popd
~
# 

All the above command are working if I'm running them as root or if /var/tmp is mounted with exec.

Created attachment 400825 [details]
Output of 'strace -f -s 128'