Consolidate SafeTokenHandle and SafeAccessTokenHandle

[venkat-raman251]

SafeTokenHandle and SafeAccessTokenHandle in corefx / src / System.Security.Principal.Windows / src / Microsoft / Win32 / SafeHandles / seem to be the same. They must be consolidated into one or needs investigation as to why they both are required.

[venkat-raman251]

@weshaggard : Who can look into this? Or is this just a placeholder for us to visit later.

[weshaggard]

It is a clean-up work-item that we will visit later. This is a perfect "up-for-grabs" item that someone in the community might be willing to pickup.

[venkat-raman251]

@weshaggard Would this item include cleaning up the Common folder? Which is currentlly inconsistent as some use SafeTokenHandle and some use SafeAccessTokenHandle

[Clockwork-Muse]

From a cursory look: the static SafeTokenHandle.InvalidHandle can be set to a valid handle. That might result in surprises later.

[Clockwork-Muse]

SafeAccessTokenHandle has a ref which is annotated with SecurityCritical, even though the src one is not.
SafeTokenHandle in the System.Security.Principal.Windows package appears to be unused.
There are additional copies in System.Security.AccessControl and System.Diagnostics.Process, one of which is identical and one which is a copy of SafeAccessTokenHandle.

System.Security.AccessControl has a reference to Principal.Windows, so presumably could use that one if it was made public (but the visibility change would likely be bad).

So should all three be consolidated into one? (presumably into Common, then)

[AlexBHarley]

@Clockwork-Muse started working on this in PR dotnet/corefx#6101 - however as of your latest comment, it seems like there is more to be done

[stephentoub]

Fixed by dotnet/corefx#6282