FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Clr type filtering by macaronikazoo · Pull Request #2742 · pythonnet/pythonnet · GitHub

  1. pythonnet
  2. pythonnet

Repository navigation

Clr type filtering - #2742

Open
macaronikazoo wants to merge 1 commit into
pythonnet:masterfrom
macaronikazoo:clr-type-filtering
ConversationCommits (1)ChecksFiles changed
Open

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

Conversation

macaronikazoo commented Sep 24, 2026 •
edited by filmor
Loading

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 commented Sep 26, 2026

Copy link
Copy Markdown
Member

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

lostmsu closed this Sep 26, 2026

macaronikazoo commented Sep 27, 2026

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 reopened this Sep 28, 2026

filmor commented Sep 28, 2026

Copy link
Copy Markdown
Member

I think this is worth discussing.

macaronikazoo commented Sep 29, 2026

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

Add IClrTypeFilter to restrict which CLR types reach Python
b21fc2c 
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

lostmsu commented Oct 13, 2026

Copy link
Copy Markdown
Member

What is the purpose?

This is not a security boundary. So why create it in the first place?

Besides, why does this functionality need to live in Python.NET? Can't Python side just remove members it wants to not expose? Why can't they can manually assemble what needs to be exposed.

macaronikazoo commented Oct 13, 2026

Copy link
Copy Markdown
Contributor Author

Not sure where else it could live - you could remove members you don't want in the current scope when initially creating the script execution environment, but you have no control during execution

In my situation we expose python scripting for users to drive our application, but we want to prevent them from casually importing clr, or calling something like GetType on a .net object and getting reflection access to the entire application - this change makes that incredibly difficult to do. Previously it was trivial and this change makes it very difficult. It's the difference between locking your front door and leaving it wide open. Someone dedicated enough can still get in - but you've done your due diligence. The security is increased by virtue of the fact that the curious hacker can no longer wreak havoc.

Lastly, the change is pretty trivial and contained, has essentially zero side effects, and no meaningful impact on performance, so I don't quite understand the resistance - unless they're purity concerns?

This branch has not been deployed

No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Show hidden characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

Back | FazBrowse Home | New Git URL