MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010126CMakeCMakepublic2010-01-12 10:512016-06-10 14:31
ReporterJohannes Felten 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
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.
Steps To Reproduce
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.
Relationships
related to 0009620closed Kitware Robot install(target ...) fails to set intermediate directory permissions correctly 
related to 0010978closed Kitware Robot Why not skip setting permissions on existing directories? 
related to 0010789closed Brad King CMake-2.8 leaves world-writable files on Linux (Mandriva Linux Cooker) 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-01-12 10:51Johannes FeltenNew Issue
2010-01-12 11:03Brad KingStatusnew => assigned
2010-01-12 11:03Brad KingAssigned To => Brad King
2010-01-12 13:58Brad KingNote Added: 0019102
2010-01-12 13:58Brad KingStatusassigned => closed
2010-01-12 13:58Brad KingResolutionopen => fixed
2010-02-08 06:00Johannes FeltenNote Added: 0019468
2010-02-08 06:00Johannes FeltenStatusclosed => feedback
2010-02-08 06:00Johannes FeltenResolutionfixed => reopened
2010-02-08 08:36Brad KingNote Added: 0019469
2010-02-08 08:39Brad KingNote Added: 0019470
2010-02-08 18:26Brad KingNote Added: 0019488
2010-06-03 10:33Brad KingRelationship addedrelated to 0010789
2010-07-13 08:48Brad KingRelationship addedrelated to 0009620
2010-07-13 08:49Brad KingRelationship addedrelated to 0010978
2011-01-18 11:18David ColeNote Added: 0024861
2011-01-18 11:41Brad KingNote Added: 0024871
2011-01-18 11:41Brad KingStatusfeedback => assigned
2012-06-25 14:29Brad KingNote Added: 0029830
2012-06-25 14:29Brad KingAssigned ToBrad King =>
2012-06-25 14:29Brad KingStatusassigned => backlog
2012-06-25 14:29Brad KingResolutionreopened => open
2016-06-10 14:27Kitware RobotNote Added: 0041640
2016-06-10 14:27Kitware RobotStatusbacklog => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:27Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0019102)
Brad King   
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   
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   
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   
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   
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   
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   
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   
2012-06-25 14:29   
Moving to backlog for reason stated in 0010126:0024871.
(0041640)
Kitware Robot   
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.