Skip to content

GROOVY-12238: SecureASTCustomizer does not check constructors, initia… - #2771

Open
paulk-asert wants to merge 1 commit into
apache:masterfrom
paulk-asert:groovy12238
Open

GROOVY-12238: SecureASTCustomizer does not check constructors, initia…#2771
paulk-asert wants to merge 1 commit into
apache:masterfrom
paulk-asert:groovy12238

Conversation

@paulk-asert

Copy link
Copy Markdown
Contributor

…lizer blocks or field initializers

SecureASTCustomizer visited the script statement block and method bodies only, so code outside a method body escaped every configured restriction: disallowedReceivers, the statement and expression allow/deny lists, and any registered StatementChecker or ExpressionChecker. With disallowedReceivers = ['java.lang.System'], a call in a constructor, a static or instance initializer block, or a field initializer all compiled and ran, while the same call in the script body was correctly rejected.

The existing filters could not reach these. A static initializer ends up in , which is synthetic and so excluded by filterMethods; instance initializers live in a separate getObjectInitializerStatements() list; and field initializers hang off FieldNode, whose property backing fields are themselves synthetic.

Add visitConstructorsAndInitializers(), applying the securing visitor to declared constructors, object initializer statements, the statements inside , and field initial expressions.

Only nodes carrying a source position are visited. Constructors and initializers are not written solely by the author of the secured source: every script class has generated constructors, and AST transformations add their own. Visiting those rejects valid programs -- a first cut broke four existing tests on the script class's generated super(Binding) call, which is not marked synthetic and so cannot be excluded by any flag. Note the wrapper block is synthetic even when its statements are not, so the check is applied per statement.

Tests cover each closed gap, keep the script-body control, and pin the exemption for generated constructors so a later simplification cannot drop the source-position check unnoticed. Both Limitations sections, in the user guide and the javadoc, are updated to match.

Constructors still do not count towards methodDefinitionAllowed, and annotation members remain unvisited; both are separable changes.

@codecov-commenter

codecov-commenter commented Aug 7, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 64.28571% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.9915%. Comparing base (384633b) to head (29c82d8).
⚠️ Report is 13 commits behind head on master.

Files with missing lines Patch % Lines
...roovy/control/customizers/SecureASTCustomizer.java 64.2857% 6 Missing and 4 partials ⚠️
Additional details and impacted files

Impacted file tree graph

@@                Coverage Diff                 @@
##               master      #2771        +/-   ##
==================================================
+ Coverage     69.9863%   69.9915%   +0.0052%     
- Complexity      35528      35551        +23     
==================================================
  Files            1557       1557                
  Lines          131693     131726        +33     
  Branches        24175      24184         +9     
==================================================
+ Hits            92167      92197        +30     
+ Misses          31192      31181        -11     
- Partials         8334       8348        +14     
Files with missing lines Coverage Δ
...roovy/control/customizers/SecureASTCustomizer.java 52.2240% <64.2857%> (+1.3620%) ⬆️

... and 8 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

…lizer blocks or field initializers

SecureASTCustomizer visited the script statement block and method bodies
only, so code outside a method body escaped every configured restriction:
disallowedReceivers, the statement and expression allow/deny lists, and any
registered StatementChecker or ExpressionChecker. With
disallowedReceivers = ['java.lang.System'], a call in a constructor, a static
or instance initializer block, or a field initializer all compiled and ran,
while the same call in the script body was correctly rejected.

The existing filters could not reach these. A static initializer ends up in
<clinit>, which is synthetic and so excluded by filterMethods; instance
initializers live in a separate getObjectInitializerStatements() list; and
field initializers hang off FieldNode, whose property backing fields are
themselves synthetic.

Add visitConstructorsAndInitializers(), applying the securing visitor to
declared constructors, object initializer statements, the statements inside
<clinit>, and field initial expressions.

Only nodes carrying a source position are visited. Constructors and
initializers are not written solely by the author of the secured source: every
script class has generated constructors, and AST transformations add their own.
Visiting those rejects valid programs -- a first cut broke four existing tests
on the script class's generated super(Binding) call, which is not marked
synthetic and so cannot be excluded by any flag.

A generated member may nonetheless contain authored code, because a
transformation can move it there: @TupleConstructor(pre=...) and
@MapConstructor(pre=...) relocate the supplied closure body into the
constructor they generate, and @asttest aside, this relocation is the usual
fate of a closure supplied as an annotation member. Such statements keep the
source position they had in the original source, so the body of a member with
no source position of its own is filtered statement by statement rather than
skipped outright. The <clinit> body is treated the same way, since that method
is always generated while its statements need not be.

Tests cover each closed gap, the two relocation cases, the script-body control,
and pin the exemption for generated constructors so a later simplification
cannot drop the source-position check unnoticed. Both Limitations sections, in
the user guide and the javadoc, are updated to match.

Constructors still do not count towards methodDefinitionAllowed, and annotation
members remain unvisited; both are separable changes.
@testlens-app

testlens-app Bot commented Aug 9, 2026

Copy link
Copy Markdown

✅ All tests passed ✅

🏷️ Commit: 29c82d8
▶️ Tests: 108906 executed
⚪️ Checks: 31/31 completed


Learn more about TestLens at testlens.app.

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.

2 participants