Manpages (/usr/share/man/man3) owned by wrong user after install

[joanbm]

Description:

When installing a package system-wide on Linux systems, it is common that the build step (make) is run as a different user than the install step (make install). Typically the build step is run as a regular (non-root) user and the install step is run as the root user.

In general, the files that are deployed by the installation should be owned by the user who ran the install step. However, zziplib's installation scripts do not respect this for the manpages (typically deployed on /usr/share/man/man3), which are deployed as the user who ran the build.

Steps to reproduce:

Run the following script in order to download, build, and install zziplib, generating a package file similarly to how Linux distributions do. Pay attention to the output of the last command:

#!/usr/bin/env bash
set -euo pipefail

wget https://github.com/gdraheim/zziplib/archive/c3de4fe291ab6756593a0ef6bad007ddd3953e00.zip -O zziplib.zip
echo "a74a1ae495a0b53af14e8efcea30e21032e09b047871b90297acc944cb196d90  zziplib.zip" | sha256sum -c
unzip zziplib.zip && cd zziplib-c3de4fe291ab6756593a0ef6bad007ddd3953e00
mkdir build && mkdir install && cd build
cmake -DCMAKE_INSTALL_PREFIX="$(realpath ../install)" ..
make && make htmpages && make manpages
fakeroot bash -c 'make install && tar czf zziplib-pkg.tar.gz -C ../install .'
tar tvf zziplib-pkg.tar.gz

Expected result:
All files in the generated package are owned by root.

Actual result:

In the generated package, the manpages are owned by the user who did the build instead of by root:

drwxr-xr-x root/root         0 2020-04-19 16:53 ./
drwxr-xr-x root/root         0 2020-04-19 16:53 ./lib/
drwxr-xr-x root/root         0 2020-04-19 16:53 ./lib/pkgconfig/
-rw-r--r-- root/root       327 2020-04-19 16:53 ./lib/pkgconfig/zziplib.pc
-rw-r--r-- root/root       346 2020-04-19 16:53 ./lib/pkgconfig/zzipmmapped.pc
[...]
-rw-r--r-- root/root      4386 2020-04-19 09:25 ./share/aclocal/zziplib.m4
drwxr-xr-x root/root         0 2020-04-19 16:53 ./share/man/
drwxr-xr-x myuser/myuser     0 2020-04-19 16:53 ./share/man/man3/
-rw-rw-r-- myuser/myuser  1489 2020-04-19 16:53 ./share/man/man3/zzip_rewinddir.3
-rw-rw-r-- myuser/myuser    21 2020-04-19 16:53 ./share/man/man3/zzip_telldir.3
-rw-rw-r-- myuser/myuser    21 2020-04-19 16:53 ./share/man/man3/zzip_seekdir.3
[...]
-rw-rw-r-- myuser/myuser    23 2020-04-19 16:53 ./share/man/man3/zzip_entry_fclose.3
-rw-rw-r-- myuser/myuser    23 2020-04-19 16:53 ./share/man/man3/zzip_entry_feof.3

Reproduced on:

• zziplib 0.13.70 and git master (c3de4fe)
• Arch Linux (updated)

Discussion / technical details:

The cause of the problem is that the procedure for installing the manpages involves creating a manpages.tar file during the build step, which is unpacked during the install step. However, tar (or at least GNU tar) defaults to setting the ownership of the unpacked files to the user who packed them when run as root, thus the files are unpacked as the user who built zziplib and not root. From man tar:

       --same-owner
              Try extracting files with the same ownership as exists in  the  archive
              (default for superuser).

A quick fix for GNU tar is passing the --no-same-owner flag to the extract command in docs/CMakeLists.txt so it looks like this:

install(CODE "execute_process(COMMAND ${BASH} -c \"set -e
   mkdir -vp $DESTDIR/${mandir} || ls -ld $DESTDIR/${mandir}
   cd $DESTDIR/${mandir} && tar xf ${CMAKE_CURRENT_BINARY_DIR}/manpages.tar --no-same-owner
   \")")

However, I believe this --no-same-owner flag is a GNU tar extension so this is not a solid solution. If possible I believe that avoiding the manpages.tar entirely and using a CMake install(DIRECTORY ...) should take care of this, but I'm not sure if there's some reason manpages.tar is used or rather is mostly legacy from old build scripts.

--

Currently Arch Linux's package fixes the permissions after install ( https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/zziplib&id=820c6821cc79a029d40710152dd3295f35bf8b99 , https://bugs.archlinux.org/task/66270 ). However this is really a upstream issue.

[gdraheim]

Thanks for the pointer, I did not see that so far - perhaps because packaging tools like rpm and deb have the habit to have a seperate list of files to be grabbed and they name the target owner and permissions alongside.

And well, you are right, the tar generation is a bit archaic from a time that "xmlto" was required to generate the manpages. The xmlto xsl stylesheets were always a bit quirky so that the tar file was committed into the source code tree whenever it was successful on my system having checked that with my bare eyes.

As the man3 directory is still in the build directory, its content could just as well be copied over to the target area as such.

[gdraheim]

Here your are, the install(DIRECTORY man3) is appended to install.cmake when the option is enabled.

[joanbm]

Thanks you for taking the time to look at this, this should make package mantainer's life a bit easier :)

Just as a last note, running the install procedure in the first post on the develop branch, the install looks for the man in /home/myuser/zziplib/docs/man3 but they are built in /home/myuser/zziplib/build/docs/man3. I think it should be install(DIRECTORY ${outdir}/man3/[...] or something like this.

[gdraheim]

After double checking for a new release, the outdir needs to be there. I had some old man3/ in the source tree which did allow me to rebuild many times before I did hit that error myself. Thanks again.