Closed Raffaello closed 7 months ago
related issue #827
I was hoping to run Travis-CI in debug mode and ssh into the container to just check the resulting rpm(s) permissions.
with this command:
rpm -q --queryformat="[%{FILEMODES:perms} %{FILEUSERNAME}:%{FILEGROUPNAME} %{FILENAMES}\n]" KTX-Software-...
but i don't have permissions on that.
I have created a podman container running ubuntu:jammy
and compiling within the container a basic debug build using the ci_script BUILD_DIR=build PACKAGE=YES ./ci_scripts/build_linux.sh
the resulting rpm package: build/KTX-Software-4.3.0-beta1-Linux-x86_64.rpm
listing the file permissions looks ok:
drwxr-xr-x root:root /usr/include/KHR # <--- this is 0755 instead of 0775
-rw-r--r-- root:root /usr/include/KHR/khr_df.h
Thank you for this.
I suspect the directory permission difference is due to the earlier version of cmake used by Travis CI (3.26.3) rather than something else in the Ubuntu environment.
Because of the repo secrets debug mode is disabled. Also packages are only deployed to GitHub Releases for version-tagged commits. Before the next release I will build a draft release and check the permissions with the command you gave.
Unfortunately it is not working on my local Ubuntu 22.04.
$ rpm -q --queryformat="[%{FILEMODES:perms} %{FILEUSERNAME}:%{FILEGROUPNAME} %{FILENAMES}\n]" KTX-Software-*.rpm
-rwxr-xr-x root:root /usr/bin/ktx
-rwxr-xr-x root:root /usr/bin/ktx2check
-rwxr-xr-x root:root /usr/bin/ktx2ktx2
-rwxr-xr-x root:root /usr/bin/ktxinfo
-rwxr-xr-x root:root /usr/bin/ktxsc
-rwxr-xr-x root:root /usr/bin/toktx
drwxrwxr-x root:root /usr/include/KHR
-rw-r--r-- root:root /usr/include/KHR/khr_df.h
-rw-r--r-- root:root /usr/include/ktx.h
-rw-r--r-- root:root /usr/include/ktxvulkan.h
drwxr-xr-x root:root /usr/lib/.build-id
drwxr-xr-x root:root /usr/lib/.build-id/4f
lrwxrwxrwx root:root /usr/lib/.build-id/4f/3bc0d541f899a3d5e2870b34841a759c213a45
drwxr-xr-x root:root /usr/lib/.build-id/6d
lrwxrwxrwx root:root /usr/lib/.build-id/6d/4ffb3d56efbf335b8e5f273558bcfb6d980be9
drwxr-xr-x root:root /usr/lib/.build-id/8c
lrwxrwxrwx root:root /usr/lib/.build-id/8c/f8b8f0212398200dbaeedbafde06e2905af7a4
drwxr-xr-x root:root /usr/lib/.build-id/a6
lrwxrwxrwx root:root /usr/lib/.build-id/a6/6441bb2ab2d55830a7bcc1ad800606a2f1c1dd
drwxr-xr-x root:root /usr/lib/.build-id/ce
lrwxrwxrwx root:root /usr/lib/.build-id/ce/04c917bb65d7cd542d75726d0b520029b2621a
drwxr-xr-x root:root /usr/lib/.build-id/d8
lrwxrwxrwx root:root /usr/lib/.build-id/d8/61939374586c6c456291e4dbf1de51bbaa2362
drwxrwxr-x root:root /usr/lib/cmake
drwxrwxr-x root:root /usr/lib/cmake/ktx
-rw-r--r-- root:root /usr/lib/cmake/ktx/KtxConfig.cmake
-rw-r--r-- root:root /usr/lib/cmake/ktx/KtxConfigVersion.cmake
-rw-r--r-- root:root /usr/lib/cmake/ktx/KtxTargets-release.cmake
-rw-r--r-- root:root /usr/lib/cmake/ktx/KtxTargets.cmake
-rw-r--r-- root:root /usr/lib/libktx-4.3.0.jar
lrwxrwxrwx root:root /usr/lib/libktx-jni.so
lrwxrwxrwx root:root /usr/lib/libktx-jni.so.4
-rw-r--r-- root:root /usr/lib/libktx-jni.so.4.3.0
lrwxrwxrwx root:root /usr/lib/libktx.so
lrwxrwxrwx root:root /usr/lib/libktx.so.4
-rw-r--r-- root:root /usr/lib/libktx.so.4.3.0
As you can see /usr/include/KHR
still has 775 permissions as do /usr/lib/cmake
and /usr/lib/cmake/ktx
.
Oh!!! You've modified the wrong file. You need to modify the root CMakeLists.txt
. The file you've modified is part of the cxxopts project that we include in ours via git subrepo
. Please update this PR and when you do capitalize the first letter of the first sentence of the comment and change it to reflect that the issue is with Ubuntu default permissions not Travis CI.
Thank you for this.
I suspect the directory permission difference is due to the earlier version of cmake used by Travis CI (3.26.3) rather than something else in the Ubuntu environment.
Because of the repo secrets debug mode is disabled. Also packages are only deployed to GitHub Releases for version-tagged commits. Before the next release I will build a draft release and check the permissions with the command you gave.
Actually it is very likely that is a bug in CPackRPM
too: I found one with manual files when building on Fedora:
https://gitlab.kitware.com/cmake/cmake/-/issues/25545
rpm -q --queryformat="[%{FILEMODES:perms} %{FILEUSERNAME}:%{FILEGROUPNAME} %{FILENAMES}\n]" KTX-Software-*.rpm
@MarkCallow I updated as you asked. But after your comment not working on ubunty, i tried doing the same building without that change and in my case is still getting the right permissions. So i guess it might not work as expected on a bare Ubuntu system.
Please let me know when you have time. Thanks
I just tried with the latest fix and can confirm it works. All directories now have 755 permissions.
But after your comment not working on ubuntu, i tried doing the same building without that change and in my case is still getting the right permissions. So i guess it might not work as expected on a bare Ubuntu system.
Check your /etc/login.defs
. Maybe it sets USERGROUPS_ENAB
or UMASK
differently to the default. Or perhaps your user is a member of a real group rather than a private user group. Do an ls -l
on some file you created. If your user name and group name are the same you have a private user group. If not, then the default umask will be 022
instead of 002
so directories will be created with mode 755
.
The fix you have provided is good protection against strange umasks though arguably CPackRPM should be making sure well known shared directories have the expected permissions.
This fixes #827, the conflicting permissions in the directories, those lead to impossibility to install the package.