On Wed, 20 May 2026 08:51:57 GMT, Kevin Walls <[email protected]> wrote:

>> Prior to this patch, when `userOnly` was true, the conflicting "allow"
>> entry (for the owner) and "deny" entry (for groups that the owner is a
>> member of) resulted in the owner being denied access since the "deny"
>> entry takes precedence.  This resulted in RmiBootstrapTest and
>> RmiSslNoKeyStoreTest tests failing with an "Access Denied" error.
>> 
>> In reality, the "deny" entry is not required, since Windows grants
>> access only when an explicit "allow" entry matches the requesting
>> principal.  So this patch fixes the ACLs so that when `userOnly` is
>> true, only the owner has "allow" access.  Principals without a matching
>> "allow" entry are denied access, thus restricting access without risking
>> a group "deny" entry overriding the owner's access.
>> 
>> This patch also fixes the case when `userOnly` is false so that it
>> doesn't inadvertently deny access when a principal didn't already have
>> an ACL entry for the file.
>> 
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the 
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Hi, are you saying these tests always fail?  I don't see failures in our 
> systems.
> Are they failing since some change, or are there particular systems or 
> configs that fail?

Hi @kevinjwalls and @AlanBateman, my understanding is that the test fails when 
(as Alan pointed out) the user running the test is also part of a group (e.g. 
"BUILTIN\Administrators").  I see this failure in [this GitHub 
workflow](https://github.com/raneashay/openjdk-jdk/actions/runs/25766044265) as 
well (look for "RmiBootstrapTest" or "RmiSslNoKeyStoreTest" but ignore other 
test failures, I'm addressing those separately).  Broadly, yes, if there's a 
DENY entry and an ALLOW entry, then the resulting action is to deny access.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/31179#issuecomment-4503061009

Reply via email to