I'm having kind of the inverse problem.
Setting an "Everyone" permission to a key and all of its values, propagates
that permission upwards on the registry tree!
The following
<RegistryKey Root='HKLM' Key='SOFTWARE\IMyRegistryFolder\MyKey'
Action='createAndRemoveOnUninstall'>
<Permission User='Everyone' GenericAll='yes'/>
<RegistryValue Type='string' Name='Name1' Value='Value1'>
<Permission User='Everyone' GenericAll='yes'/>
</RegistryValue>
</RegistryKey>
</RegistryKey>
Will set both keys: MyKey and MyRegistryFolder to have Everyone user with
full control on.
I've also tried "declaring" the keys separately with the same result.
The oddest case I'm experiencing can be seen in the following example:
<RegistryKey Root='HKLM' Key='SOFTWARE\MyRegistryKey'
Action='createAndRemoveOnUninstall'>
<RegistryKey Key="Subkey1" Action='createAndRemoveOnUninstall'>
<Permission User='Administrators' GenericAll='yes'/>
<RegistryKey Key="Subkey2" Action='createAndRemoveOnUninstall'>
<Permission User='Everyone' GenericAll='yes'/>
<RegistryValue Type='string' Name='Name1' Value='Value1'>
<Permission User='Everyone' GenericAll='yes'/>
</RegistryValue>
</RegistryKey>
</RegistryKey/>
</RegistryKey/>
</RegistryKey>
In this case:
- MyRegistryKey has "Everyone" user with full control
- Subkey1 has "Administrators" use with full control (and does not have
Everyone user)
- Subkey2 has "Everyone" user with full control
I'm using wix 3.5. Windows Installer 4.
Is there anything wrong in what I'm doing?
Thanks and regards
2011/8/8 James Johnston <johnst...@inn-soft.com>
> I replaced "Permission" with "util:PermissionEx" in the sample below.
> Unfortunately, ordinary users are still not allowed to write to MySubKey.
> An examination of the permissions in Registry Editor shows that entries
> were
> added to the existing ACL for "MyFile". (i.e. the existing entries were
> not
> stepped on like the old "Permission" element did - a good thing). But they
> were set to only apply to the current key, and not to subkeys - no
> inheritance.
>
> An examination of the custom action code in "secureobj.cpp" shows
> "ea.grfInheritance = NO_INHERITANCE" if the object is not a
> folder/directory. Now this is with WiX 3.0 sources but I searched the
> tracker and apparently somebody else reported the same issue last year with
> WiX 3.5 and it hasn't been looked at yet:
>
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=3029343&group_id=10
> 5970&atid=642717<http://sourceforge.net/tracker/index.php?func=detail&aid=3029343&group_id=105970&atid=642717>
> Another similar ticket:
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2612975&group_id=1
> 05970&atid=642717<https://sourceforge.net/tracker/index.php?func=detail&aid=2612975&group_id=105970&atid=642717>
> And one more:
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=1241592&group_id=1
> 05970&atid=642717<https://sourceforge.net/tracker/index.php?func=detail&aid=1241592&group_id=105970&atid=642717>
> And finally:
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2991460&group_id=1
> 05970&atid=642714<https://sourceforge.net/tracker/index.php?func=detail&aid=2991460&group_id=105970&atid=642714>
> (all seem to be duplicates)
>
> In fact looking at the WiX 3.6 code shows this code is still unmodified and
> in place. So this explains why I still have issues with util:PermissionEx.
>
> It seems to me that the best solution would be to specify inheritance via
> attribute, just as the tracker suggests. I can't think of a workaround
> when
> using util:PermissionEx because subkeys created later by my application
> will
> not inherit the "Everyone" entry and so other users won't be able to read
> it... So this raises two questions:
>
> 1. Any good workaround to get things inheriting properly?
> 2. Any feedback on the previous feature requests? I notice that an active
> subscriber actually posted a patch. But this was 3 years ago; it seems it
> didn't go anywhere? See:
>
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PermissionEx-e
> nhancements-wix-Bugs-2127236-2016138-td1303935.html<http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PermissionEx-enhancements-wix-Bugs-2127236-2016138-td1303935.html>
> Also see a follow-up:
>
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Chnaged-to-Cod
> y-Cutrer-s-SecureObjects-enhancements-tt1563118.html<http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Chnaged-to-Cody-Cutrer-s-SecureObjects-enhancements-tt1563118.html>
>
> I was originally thinking of offering to implement this feature as I would
> like to see this happen, but after seeing that somebody else already did
> and
> nothing really seemed to happen with it - I am not sure if that would be
> worth my time. (Also I have no idea what is involved with contributing to
> WiX - I haven't been able to find a web page describing how this process
> works for WiX - many open source projects have an entire page dedicated to
> this topic). I am left scratching my head... Is this something that will
> eventually become part of a future WiX version, or were there reasons for
> not merging code for the new feature? Or does the code need more work? It
> would be nice to not have to constantly merge an old patch with every new
> version of WiX. :)
>
> Best regards,
>
> James Johnston
>
> -----Original Message-----
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Saturday, August 06, 2011 14:56
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Registry permissions are not inherited
>
> That is the behavior of the Windows Installer. Take a look at the
> WixUtilExtension PermissionEx.
>
> On Fri, Aug 5, 2011 at 12:44 PM, James Johnston
> <johnst...@inn-soft.com>wrote:
>
> > Hi,
> >
> > I'm trying to create some default registry keys for a component in
> > HKEY_LOCAL_MACHINE that all users should have full access to. Here's
> > what I've got so far:
> >
> > <Component Id="MyFile.dll" Guid="*">
> > <File Id="MyFile.dll" KeyPath="yes" Source="MyFile.dll" />
> > <RegistryKey Action="create" Key="SOFTWARE\MyCompany" Root="HKLM">
> > <RegistryKey Action="create" Key="MyFile">
> > <Permission User="Everyone" GenericAll="yes" />
> > <Permission User="Administrators" GenericAll="yes" />
> > <RegistryKey Action="create" Key="MySubKey">
> > <RegistryValue Name="MyValue" Type="integer" Value="1" />
> > </RegistryKey>
> > </RegistryKey>
> > </RegistryKey>
> > </Component>
> >
> > The keys I would like created:
> >
> > * HKLM\SOFTWARE\MyCompany: should have default ACL that users cannot
> > write to (inherit from parent)
> > * HKLM\SOFTWARE\MyCompany\MyFile: all users should have read/write
> > access to this key
> > * HKLM\SOFTWARE\MyCompany\MyFile\MySubKey: all users should have
> > read/write access to this key (inherit from parent)
> >
> > Unfortunately, the last key seems to be created with an ACL that only
> > allows administrators to write to the key (same ACL as for the main
> > "SOFTWARE"
> > key). Intuitively I would think that the RegistryKey underneath the
> > key granting everyone access would also grant everyone access. But
> > that seems not to be the case.
> >
> > Most puzzling is that examining "MySubKey" in the registry editor
> > shows that the "Include inheritable permissions from this object's
> > parent" is checked.
> > And creating new keys under "MyFile" key in registry editor works just
> > fine when running as a user - so the permissions are inherited.
> > Looking at the ACL entry for "Everyone" on "MyFile" key says that the
> > entry applies to "this key and subkeys" so again, I'm not sure why it
> isn't working.
> >
> > What do I need to do to achieve my goal of having the "Everyone" entry
> > propagate to the subkeys created by MSI - as outlined in my list of
> > desired ACLs? I realize I could probably add duplicate "Permission"
> > elements to the registry values being created. But that doesn't sound
> > very ideal; it seems like there must be a better way!
> >
> > Best regards,
> >
> > James Johnston
> >
> >
> >
> > ----------------------------------------------------------------------
> > -------- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco,
> > CA The must-attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
>
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
>
> ----------------------------------------------------------------------------
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Francisco Gabriel Malbrán
Licenciado en Ciencias de la Computación
Online CV: www.linkedin.com/in/franciscomalbran
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
