[cmake-developers] Clarification requested on #10126 (CMake creates files with wrong permissions)
Brad King
brad.king at kitware.com
Mon Aug 17 11:51:03 EDT 2015
On 08/16/2015 05:52 PM, James Johnston wrote:
> a. So to clarify, you'd want existing OWNER_* / GROUP_* / EXECUTE_*
> options to remain unmodified? i.e. if you install(PERMISSIONS GROUP_WRITE)
> this will still NOT respect the umask, correct? (i.e. the only way to
> respect the umask would be to use the NEW READ/WRITE/EXECUTE options?)
That was the in-issue proposal but it is just a starting point for discussion.
> b. If the answer to (a) is yes, what do you want to do if the user
> specifies install(PERMISSIONS WRITE GROUP_WRITE)? Is that an error?
As originally proposed I think that would be an error. The idea was to
simplify the basic permissions specification except in cases where very
specific permissions are needed. I think most projects could just switch
to the new/simpler keywords outright and let local umask settings take
care of the details.
> c. Would it be better to introduce a new permissions keyword for
> respecting the umask for the entire set of keywords? E.g.
> install(PERMISSIONS RESPECT_UMASK GROUP_WRITE).
I think that could make sense as an additional/separate change to the
above.
> 2. Proposal to modify default permission copying of configure_file and
> friends: I may have questions here but haven't thought it through yet.
>
> Finally, to resolve the issue as reported by the original submitter:
>
> Fix works almost perfectly, yet there are some files still having 0644
> rights:
> in builddir/CMakeFiles/ it's
> - CMakeCCompiler.cmake
> - CMakeCXXCompiler.cmake
> - CMakeSystem.cmake
>
> 3. Won't the proposal from #2 above fix this problem?
Possibly. What configure_file behavior do you propose? One possibility
is to just take the input owner rwx bits and map to READ WRITE EXECUTE
keyword permissions as discussed above.
There are several CMake APIs that create files so it would also be
nice to have a consistent permissions API for all of them. Some are
still missing any permissions API at all.
Thanks,
-Brad
More information about the cmake-developers
mailing list