KhronosGroup / KTX-Software

KTX (Khronos Texture) Library and Tools
Other
854 stars 226 forks source link

Fix RPM default directory permission #830

Closed Raffaello closed 7 months ago

Raffaello commented 7 months ago

This fixes #827, the conflicting permissions in the directories, those lead to impossibility to install the package.

CLAassistant commented 7 months ago

CLA assistant check
All committers have signed the CLA.

Raffaello commented 7 months ago

related issue #827

Raffaello commented 7 months ago

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
MarkCallow commented 7 months ago

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.

MarkCallow commented 7 months ago

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.

Raffaello commented 7 months ago

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

Raffaello commented 7 months ago

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

MarkCallow commented 7 months ago

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.