MantisBT - CMake
View Issue Details
0014924CMakeCPackpublic2014-05-22 03:442015-01-05 08:39
Richard Ulrich 
Nils Gladitz 
normalfeaturealways
closedfixed 
 
CMake 3.1 
0014924: Setting file permissions for the cpack WiX generator through install properties
This is an extension to http://public.kitware.com/Bug/view.php?id=14911. [^]
As this mechanism works so well, it would be great if we could use it for other attributes as well.

My commandline program, that I used so far for for the neverOverwrite and permanent attributes, also sets the file permissions like this:

<Component Id="CM_CP_module.mod.kueche._userlib_.LibraryFilter.conf" Guid="*" NeverOverwrite="yes" Permanent="yes">
  <File Id="CM_FP_module.mod.kueche._userlib_.LibraryFilter.conf" Source="C:/OtherRepos/PlPython/build_ex/_CPack_Packages/win32/WIX/PointLineParamLib22-22.2.0-win32/module/mod/kueche/_userlib_/LibraryFilter.conf" KeyPath="yes">
    <Permission User="Everyone" GenericAll="yes"/>
  </File>
</Component>

Now it would be great if I could also use the install properties for that. For example like this:

SET_PROPERTY(INSTALL ${FILES_IN_USERLIB} PROPERTY CPACK_PERMISSION_USER Everyone)
SET_PROPERTY(INSTALL ${FILES_IN_USERLIB} PROPERTY CPACK_PERMISSION_GENERIC_ALL ON)
No tags attached.
Issue History
2014-05-22 03:44Richard UlrichNew Issue
2014-05-22 03:48Nils GladitzAssigned To => Nils Gladitz
2014-05-22 03:48Nils GladitzStatusnew => assigned
2014-05-22 04:18Nils GladitzNote Added: 0035907
2014-05-22 07:41Richard UlrichNote Added: 0035908
2014-05-22 08:07Nils GladitzNote Added: 0035909
2014-08-09 09:41Nils GladitzNote Added: 0036584
2014-08-29 10:02Nils GladitzNote Added: 0036690
2014-08-29 10:02Nils GladitzStatusassigned => resolved
2014-08-29 10:02Nils GladitzFixed in Version => CMake 3.1
2014-08-29 10:02Nils GladitzResolutionopen => fixed
2015-01-05 08:39Robert MaynardNote Added: 0037622
2015-01-05 08:39Robert MaynardStatusresolved => closed

Notes
(0035907)
Nils Gladitz   
2014-05-22 04:18   
Some random thoughts ...

To allow multiple ACLs for different users it will probably be easier to use a single property. e.g. CPACK_WIN32_ACL.

Since property values can be lists each list item could result in one <Permission> element.

I am hoping windows already has some standard format for ACL specifications in compact string form that could be used for this.
Perhaps there is even something more generic that could be used with other ACL implementations.

It might also be something that could be supported by the install target (without CPack) so perhaps a "WIN32_ACL" property (without CPACK_ prefix).

I assume the install script could only be allowed to set them when not being invoked by CPack with the WIX generator since ACLs on the intermediate files might prevent them from being packaged.
(0035908)
Richard Ulrich   
2014-05-22 07:41   
I remember havin seen something about permissions in the cmake documentation, so I did a quick readup.
Actually, for my use case, it would suffice to add
<Permission User="Everyone" GenericAll="yes"/>

If I do:
INSTALL(FILES ${FILES_IN_MOD}
   DESTINATION module/mod
   PERMISSIONS WORLD_WRITE
   COMPONENT app
)

But that might be difficult to scale.
(0035909)
Nils Gladitz   
2014-05-22 08:07   
The permissions used by CMake in that context are based on unix permissions.
I think OWNER_WRITE is the only permission that has any effect on windows currently (see 0014439).

If install() were to implicitly set INSTALL properties based on those permissions I might be able to create ACLs from them though.

Might get complicated when both unix permissions and ACLs are present/implemented.
(0036584)
Nils Gladitz   
2014-08-09 09:41   
I merged an implementation for a new CPACK_WIX_ACL property to next which stays close to the WiX <Permission> element.

I couldn't find a really nice way to support more generic ACL specifications or even map the windows specific compact ACL specifications to the <Permission> element.
(0036690)
Nils Gladitz   
2014-08-29 10:02   
Implemented by http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=401d82b3db7253d29e51ecc7c7cdbaee70a38166;hp=8b61070748ce7de7c7ad3a21b9fa6b3bc5281e4f [^]
(0037622)
Robert Maynard   
2015-01-05 08:39   
Closing resolved issues that have not been updated in more than 4 months