When permissions are assigned to the registry, multiple code paths can be used. When querying/maintaining ACLs/ACEs with .NET, any ACEs defined with the COM code path will not translate correctly. This is why one would observe a value of -2147483648 (Generic Read) and 268435456 (Full Control) for RegistryRights with some ACEs. Any principal other than APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES is handled correctly. However, there's a workaround that has to be performed when manipulating access rules with the formerly mentioned principal. The workaround involves creating a new access rule with the SID for ALL APPLICATION PACKAGES then performing an action to the ACL, whether it's a remove or add. This workaround is not viable since the translated RegistryRights in these cases aren't valid RegistryRights enumerations. Code will have to be developed to handle removing these ACEs when the scenario is encountered.
This will require additional code than what was addressed for Issue #37
When permissions are assigned to the registry, multiple code paths can be used. When querying/maintaining ACLs/ACEs with .NET, any ACEs defined with the COM code path will not translate correctly. This is why one would observe a value of -2147483648 (Generic Read) and 268435456 (Full Control) for RegistryRights with some ACEs. Any principal other than APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES is handled correctly. However, there's a workaround that has to be performed when manipulating access rules with the formerly mentioned principal. The workaround involves creating a new access rule with the SID for ALL APPLICATION PACKAGES then performing an action to the ACL, whether it's a remove or add. This workaround is not viable since the translated RegistryRights in these cases aren't valid RegistryRights enumerations. Code will have to be developed to handle removing these ACEs when the scenario is encountered.
This will require additional code than what was addressed for Issue #37