Runtime: Thread never sets _principal

[ericstj]

I came across some desktop code that depends on accessing Thread.CurrentPrincipal and expects a legit concrete WindowsPrincipal however we never set this value and it will always return null.

At least on Windows we could set it to new WindowsPrincipal(WindowsIdentity.GetCurrent());, potentially via lightup.

[danmosemsft]

@stephentoub any concerns? The minimal change sounds easy.

[jkotas]

The type of the principal to create should be based on policy set by AppDomain.SetPrincipalPolicy.

.NET Framework does not create WindowsPrincipal by default, so .NET Core should not be creating one by default either.

[jkotas]

.NET Core is hardcoded to "NoPrincipal" default policy today. I would keep this default for .NET Core. It is trivial for apps to override it using AppDomain.SetPrincipalPolicy if they need to.

[danmosemsft]

OK looks like work then is (1) port AppDomain.GetThreadPrincipal() and make sure default is PrincipalPolicy.NoPrincipal (2) wire up Thread.CurrentPrincipal to it (3) make AppDomain.SetPrincipalPolicy set it. With tests.

[danmosemsft]

@Anipik this seems pretty easy.

[jkotas]

I think you will run into layering cycle between System.Runtime.Extensions and System.Threading.Thread. You can hack around them via reflection, or you can fold the multiple together into System.Runtime.Extensions. The latter one would be my preference.

[ericstj]

You may also have dependency issues with System.Security.Principal.Windows.

Also, double check the interaction between SetPrincipalPolicy and GetThreadPrincipal and other releated APIs. It's a bit nuanced: I think it will only have an impact if set before the first Get.

[stephentoub]

@stephentoub any concerns?

Sounds fine.