Skip to content

Fix installed basis.h getting restrictive (0600) permissions#421

Open
evaleev wants to merge 2 commits into
masterfrom
fix/basis-h-install-permissions
Open

Fix installed basis.h getting restrictive (0600) permissions#421
evaleev wants to merge 2 commits into
masterfrom
fix/basis-h-install-permissions

Conversation

@evaleev
Copy link
Copy Markdown
Owner

@evaleev evaleev commented May 31, 2026

Problem

On some Linux installs the installed include/libint2/basis.h ends up with 0600 permissions (owner-only), making it unreadable to other users, while every other installed header is 0644. macOS installs are unaffected.

Root cause

basis.h is the only public header generated directly during install via install(CODE …), so it does not go through install(FILES) normalization. If generated/copied with source-permission inheritance, restrictive mode bits from basis.h.in can propagate to the installed header.

Fix

Avoid source-permission inheritance entirely and explicitly install basis.h as 0644 in a CMake-3.16-compatible way:

  • configure_file() now generates basis.h into the build tree first.
  • file(COPY … FILE_PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ) then copies it into the install include directory, pinning installed mode to 0644.
  • The in-tree install path now also prepends $ENV{DESTDIR} so staged/package installs land in the staging root correctly.

Applied in both:

  • export/CMakeLists.txt.export (exported project used by end users)
  • src/lib/libint/CMakeLists.txt (generator in-tree copy)

basis.h is the only public header generated directly into the install
prefix via configure_file() inside an install(CODE) block (so that
LIBINT_DATADIR_ABSOLUTE reflects a --prefix override). configure_file()
defaults to USE_SOURCE_PERMISSIONS, so the installed header inherits the
mode of basis.h.in. When basis.h.in happens to be 0600 in the build
environment (restrictive umask at checkout/extract), the installed
basis.h ends up 0600, unreadable to other users.

Other generated headers (e.g. config2.h) avoid this because they pass
through install(FILES), which applies a fixed 0644 rather than
preserving source permissions.

Add NO_SOURCE_PERMISSIONS to the configure_file() so the installed
basis.h always gets the standard 0644, independent of the build env.
@evaleev evaleev force-pushed the fix/basis-h-install-permissions branch from 2094158 to a6f9776 Compare May 31, 2026 23:08
@evaleev evaleev requested a review from Copilot June 1, 2026 17:40
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR addresses an installation-permissions issue where the generated public header include/libint2/basis.h can end up installed as 0600 on some Linux systems (unreadable to other users), by ensuring the install-time generation step does not inherit restrictive source permissions.

Changes:

  • Add NO_SOURCE_PERMISSIONS to the install-time configure_file() that generates basis.h in the in-tree build (src/lib/libint/CMakeLists.txt).
  • Add NO_SOURCE_PERMISSIONS to the equivalent install-time configure_file() in the exported-library template (export/CMakeLists.txt.export).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
src/lib/libint/CMakeLists.txt Adjusts install-time generation of basis.h to avoid inheriting restrictive permissions.
export/CMakeLists.txt.export Applies the same permission-handling change to the exported/library CMake template used by end users.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/lib/libint/CMakeLists.txt Outdated
Comment on lines +234 to +238
configure_file(
\"${PROJECT_SOURCE_DIR}/include/libint2/basis.h.in\"
\"\${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_INCLUDEDIR}/libint2/basis.h\"
@ONLY)
@ONLY
NO_SOURCE_PERMISSIONS) # else installed basis.h inherits basis.h.in's perms (e.g. 0600), which vary by build env
Comment on lines 789 to 797
install(CODE "
set(LIBINT_VERSION \"${LIBINT_VERSION}\")
set(LIBINT_DATADIR_ABSOLUTE \"\${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_DATADIR}/libint/${LIBINT_VERSION}\")
configure_file(
\"${PROJECT_SOURCE_DIR}/include/libint2/basis.h.in\"
\"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${LIBINT2_INSTALL_INCLUDEDIR}/libint2/basis.h\"
@ONLY)
@ONLY
NO_SOURCE_PERMISSIONS) # else installed basis.h inherits basis.h.in's perms (e.g. 0600), which vary by build env
")
…only NO_SOURCE_PERMISSIONS

- configure_file into the build tree, then file(COPY ... FILE_PERMISSIONS)
  into the install tree, giving the installed basis.h a fixed 0644 mode
  without configure_file's NO_SOURCE_PERMISSIONS (which needs CMake 3.19,
  but the exported project declares cmake_minimum_required 3.16).
- prepend $ENV{DESTDIR} in the in-tree src/lib/libint copy too, so staged
  installs write into the staging root rather than the real prefix
  (matching the exported-library template).
@evaleev
Copy link
Copy Markdown
Owner Author

evaleev commented Jun 1, 2026

Thanks @copilot — both points addressed in b575c73:

  1. DESTDIR in the in-tree copy (src/lib/libint/CMakeLists.txt): now prepends $ENV{DESTDIR}, matching the exported template, so staged/packaging installs write into the staging root rather than the real prefix.

  2. NO_SOURCE_PERMISSIONS vs the 3.16 minimum (export/CMakeLists.txt.export): dropped NO_SOURCE_PERMISSIONS (CMake 3.19+) entirely. Both files now configure_file into the build tree and then file(COPY … FILE_PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ) into the install tree. This pins the installed basis.h to 0644 regardless of basis.h.in's mode and works on CMake 3.16+, so configuring with 3.16–3.18 no longer fails.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants