View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010126CMakeCMakepublic2010-01-12 10:512016-06-10 14:31
ReporterJohannes Felten 
Assigned ToKitware Robot 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010126: CMake creates files with wrong permissions
DescriptionCMake generates files with different file-permissions, eg. in $CMAKE_CURRENT_BINARY_DIR/CMakeFiles a file 'progress.make' with group-permissions set to ReadOnly, whereas a file 'Makefile.cmake' with group-permissions set to ReadWrite. This makes it impossible to have User A to configure and run make, and another User B to run re-configure, even if both users are within the same group of users.
Additional InformationWas tracked down to Source/kwsys/ProcessUNIX.c in function kwsysProcessSetupOutputPipeFile. CMake sets the permissions explicitly to 644 here. Might be elswhere too.
TagsNo tags attached.
Attached Files

related to 0009620closedKitware Robot install(target ...) fails to set intermediate directory permissions correctly 
related to 0010978closedKitware Robot Why not skip setting permissions on existing directories? 
related to 0010789closedBrad King CMake-2.8 leaves world-writable files on Linux (Mandriva Linux Cooker) 

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.
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.
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:


If you hack your installation to give these files permissions 0664 then the configured versions should also have such permissions.
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:

    DIRECTORY Modules ...

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.
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


would cause files to be created with "0666" subject to the umask, and code like


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.
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.

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.
Brad King (manager)
2012-06-25 14:29

Moving to backlog for reason stated in 0010126:0024871.
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

Copyright © 2000 - 2018 MantisBT Team