Manual download method for hyperspec installer requires unusual file owner.

[Paul Whittaker]

Binary package hint: hyperspec

System:

 Description: Ubuntu 10.04.1 LTS
 Release: 10.04

Package:

 hyperspec 1.28

In order to work around a network problem which was preventing the automated download of the HyperSpec tarball, I used the "download the tarball manually" method for supplying the tarball to the install script.

(In case it is not obvious, I'm referring to the following sequence of steps:
 1. Download tarball to right location.
 2. Install hyperspec package via aptitude.
 3. Package's postinst script finds the tarball downloaded in 1. and does not automatically download it from the Lispworks FTP site.
 4. HyperSpec files are installed in /usr/share/doc/hyperspec.)

As aptitude does not seem to ask the debconf questions (see bug #683240) I read the installer's postinst file to find the path for the downloaded file, /root/tmp/HyperSpec-7-0.tar.gz. Whilst reading the postinst script, I noticed that despite the file being looked for in root's home directory, the postinst script explicitly checks that the file is *not* owned by root, and that it is not in root's group. If either check fails, the file will be deleted and a new one downloaded. This check is done in the function "check_archive()" with the following test sequence:

[ -s "$FILE" -a ! -L "$FILE" -a ! -O "$FILE" -a ! -G "$FILE" ]

-O and -G check that "$FILE" (/root/tmp/HyperSpec-7-0.tar.gz) is owned by the current effective UID and GID (which I believe should be root), but then the ! then negates both of these tests. As a result, after downloading the tarball and putting it in the right place, I had to (as root) chown it back to my normal user before it could be used by the postinst script. I also confirmed that a root-owned file at the same location was deleted.

I would expect the file to be checked *for* root ownership (to make it harder for users to pass malicious files to the installer), rather than requiring it *not* to have root ownership. There may well be a good reason for this, and in that case I would instead expect there to be some instructions about changing the file's owner, as most users in this situation would use sudo to save the file in /root/tmp and therefore give it the wrong owner. Alternatively, if I've simply been using aptitude as a user that wasn't envisaged (e.g. logged in as root vs. via sudo) then a specific user should be tested for, rather than making assumptions about what "the current" user is (or isn't).