Skip to content

Clr type filtering - #2742

Open
macaronikazoo wants to merge 1 commit into
pythonnet:masterfrom
macaronikazoo:clr-type-filtering
Open

macaronikazoo wants to merge 1 commit into
pythonnet:masterfrom
macaronikazoo:clr-type-filtering

Conversation

@macaronikazoo

@macaronikazoo macaronikazoo commented Sep 24, 2026 •

Copy link
Copy Markdown
Contributor

What does this implement/fix? Explain your changes.

Allows embedders to restrict which CLR types reach Python

NOTE: this isn't a security feature, but it does make it harder to go exploring through everything available in the runtime

For example, the following prevents python from using reflection.

sealed class DenyReflectionTypes : IClrTypeFilter
{
    static readonly string[] _deniedNamespaces = [
        "System.Reflection",
        "System.Runtime.InteropServices",
        "System.Runtime.Loader",
    ];

    static readonly Type[] _deniedTypes = [
        typeof(Activator),
        typeof(AppDomain),
    ];

    public bool ShouldReflect(Type type)
    {
        if (typeof(Type).IsAssignableFrom(type) || Array.IndexOf(_deniedTypes, type) >= 0)
            return false;

        if (type.Namespace is not { } ns)
            return true;
        foreach (var denied in _deniedNamespaces)
            if (ns == denied || ns.StartsWith(denied + ".", StringComparison.Ordinal))
                return false;
        return true;
    }
}

Checklist

Check all those that are applicable and complete.

  • Make sure to include one or more tests for your change
  • If an enhancement PR, please create docs and at best an example
  • Ensure you have signed the .NET Foundation CLA

@lostmsu

lostmsu commented Sep 26, 2026

Copy link
Copy Markdown
Member

@filmor this seems very out of scope. Reopen if disagree.

@lostmsu lostmsu closed this Sep 26, 2026
@macaronikazoo

Copy link
Copy Markdown
Contributor Author

why "very out of scope"? I'd have thought plently of embedders/consumers of this library would want to be able to restrict what python can and can't access on the .net side of things, surely? seems super useful - jint has similar functionality

@filmor filmor reopened this Sep 28, 2026
@filmor

filmor commented Sep 28, 2026

Copy link
Copy Markdown
Member

I think this is worth discussing.

@macaronikazoo

Copy link
Copy Markdown
Contributor Author

is there anything from me that might be helpful?

to me it seems like a potentially valuable, low risk change - the existing architecture made it reasonably easy to insert the appropriate checks - its a pretty fantastic library really, you guys have done an awesome job

Embedders can register filters on InteropConfiguration.ClrTypeFilters to refuse CLR types before they're handed to Python. Empty by default - a type is allowed only if every registered filter permits it

ReflectedClrType.GetOrCreate consults the filters on a cache miss, before taking _cacheCreateLock, so filter code never runs while a pythonnet lock is held. Every CLR type passes through there, so the one check covers return values, fields, iterators and APIs returning System.Type alike. Refused types are checked everytime, but a refusal throws ClrTypeFilteredException, which Exceptions.SetError raises as a plain Python TypeError: wrapping the CLR exception would mean reflecting its type into Python, which the same filters may refuse. InterfaceObject now guards __implementation__ and __raw_implementation__, which expose the concrete object and so can be refused too

NOTE: this isn't a security feature, but it does make it harder to go exploring through everything available in the runtime

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants