Notes
(0019102) Brad King (manager) 2010-01-12 13:58	I've committed change "Trust umask for file permissions" to address this problem everywhere I could find. Source/kwsys/ProcessUNIX.c rev 1.93 Source/cmFileCommand.cxx rev 1.143 Source/cmWriteFileCommand.cxx rev 1.19 All the open modes are converted to '0666' to be no more restrictive than the umask.

(0019468) Johannes Felten (reporter) 2010-02-08 06:00	Fix works almost perfectly, yet there are some files still having 0644 rights: in builddir/CMakeFiles/ it's - CMakeCCompiler.cmake - CMakeCXXCompiler.cmake - CMakeSystem.cmake Couldn't figure out how these files get created, so I can't tell whether there are others.

(0019469) Brad King (manager) 2010-02-08 08:36	CMakeCCompiler.cmake is created (and later re-created) by calls to the configure_file() command in Modules/CMake(Determine\|Test)CCompiler.cmake to record some information about the C compiler. Similarly for CMakeCXXCompiler.cmake. CMakeSystem.cmake is configured by Modules/CMakeDetermineSystem.cmake. The configure_file() command copies/edits a file from some source to a destination. It copies the permissions from the source location. In this case the sources are: Modules/CMakeCCompiler.cmake.in Modules/CMakeCXXCompiler.cmake.in Modules/CMakeSystem.cmake.in If you hack your installation to give these files permissions 0664 then the configured versions should also have such permissions.

(0019470) Brad King (manager) 2010-02-08 08:39	The input files get installed by the install() command called from CMake's own top CMakeLists.txt file: INSTALL( DIRECTORY Modules ... FILE_PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ ...) One possible upstream fix is to change these permissions. I don't know if everyone wants their modules to be group writable though. Another possible fix is to add an HONOR_UMASK option to configure_file() that changes how it determines the output file permissions. I'll have to discuss this with other developers.

(0019488) Brad King (manager) 2010-02-08 18:26	The full fix for this is as follows: (1) Teach the install() command (and other commands that have a mode API) new modes called just READ, WRITE, and EXECUTE. When applied, the permissions get duplicated for owner, group, and world bits subject to the umask. Then code like INSTALL(... FILE_PERMISSIONS READ WRITE ...) would cause files to be created with "0666" subject to the umask, and code like INSTALL(... FILE_PERMISSIONS READ WRITE EXECUTE ...) would cause files to be created with "0777" subject to the umask. This will allow a very concise way to get standard behavior. (2) Teach configure_file() and other places that copy permissions from some input file, such as the USE_SOURCE_PERMISSIONS option of some commands, to (optionally?) use only the OWNER mode bits from the input. The owner mode bits would be used for owner, group, and world bits, subject to the umask as above. This is appropriate because the whole reason that configure_file() copies input permissions is to preserve the executable bits on scripts. It may be desirable for this "option" to be the default because otherwise many calls to configure_file() in many projects would have to be updated with the option (and new calls would probably leave out the option accidentally). In order to make this the default we need to introduce a new CMake Policy to handle compatibility. Policy introduction must be done carefully and generally involves sweeps through code to correct the same wrong behavior everywhere it occurs. This will require a careful evaluation of every place that creates files...a non trivial task.

(0024861) David Cole (manager) 2011-01-18 11:18	Looking at "older" "feedback" status bugs today... is this still an issue that we want to address moving forward? If so, please remove the "feedback" status and just set it to "assigned"... If not, please resolve it. Thanks.

(0024871) Brad King (manager) 2011-01-18 11:41	The way forward is outlined in 0010126:0019488, but I have no time to do it now. Changing back to "assigned" for now.

(0029830) Brad King (manager) 2012-06-25 14:29	Moving to backlog for reason stated in 0010126:0024871.

(0041640) Kitware Robot (administrator) 2016-06-10 14:27	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2010-01-12 10:51	Johannes Felten	New Issue
2010-01-12 11:03	Brad King	Status	new => assigned
2010-01-12 11:03	Brad King	Assigned To	=> Brad King
2010-01-12 13:58	Brad King	Note Added: 0019102
2010-01-12 13:58	Brad King	Status	assigned => closed
2010-01-12 13:58	Brad King	Resolution	open => fixed
2010-02-08 06:00	Johannes Felten	Note Added: 0019468
2010-02-08 06:00	Johannes Felten	Status	closed => feedback
2010-02-08 06:00	Johannes Felten	Resolution	fixed => reopened
2010-02-08 08:36	Brad King	Note Added: 0019469
2010-02-08 08:39	Brad King	Note Added: 0019470
2010-02-08 18:26	Brad King	Note Added: 0019488
2010-06-03 10:33	Brad King	Relationship added	related to 0010789
2010-07-13 08:48	Brad King	Relationship added	related to 0009620
2010-07-13 08:49	Brad King	Relationship added	related to 0010978
2011-01-18 11:18	David Cole	Note Added: 0024861
2011-01-18 11:41	Brad King	Note Added: 0024871
2011-01-18 11:41	Brad King	Status	feedback => assigned
2012-06-25 14:29	Brad King	Note Added: 0029830
2012-06-25 14:29	Brad King	Assigned To	Brad King =>
2012-06-25 14:29	Brad King	Status	assigned => backlog
2012-06-25 14:29	Brad King	Resolution	reopened => open
2016-06-10 14:27	Kitware Robot	Note Added: 0041640
2016-06-10 14:27	Kitware Robot	Status	backlog => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:27	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed