Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8354053: Remove unused JavaIOFilePermissionAccess #24603

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

RogerRiggs
Copy link
Contributor

@RogerRiggs RogerRiggs commented Apr 11, 2025

The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed.
The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission.
Modernized the initialization from the system property jdk.io.permissionsUseCanonicalPath.
The remaining support will be removed when FilePermission is removed.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8354053: Remove unused JavaIOFilePermissionAccess (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24603/head:pull/24603
$ git checkout pull/24603

Update a local copy of the PR:
$ git checkout pull/24603
$ git pull https://git.openjdk.org/jdk.git pull/24603/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 24603

View PR using the GUI difftool:
$ git pr show -t 24603

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24603.diff

Using Webrev

Link to Webrev Comment

The interface is removed from SharedSecrets and its implementation
moved to the java.io package where cross package access is not needed.
The test is updated to access the internal implementation.
Moderized the initialization of jdk.io.permissionsUseCanonicalPath.
The remaining support can be removed when FilePermission is removed.
@bridgekeeper
Copy link

bridgekeeper bot commented Apr 11, 2025

👋 Welcome back rriggs! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Apr 11, 2025

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk openjdk bot added the rfr Pull request is ready for review label Apr 11, 2025
@openjdk
Copy link

openjdk bot commented Apr 11, 2025

@RogerRiggs The following labels will be automatically applied to this pull request:

  • core-libs
  • security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added security security-dev@openjdk.org core-libs core-libs-dev@openjdk.org labels Apr 11, 2025
@mlbridge
Copy link

mlbridge bot commented Apr 11, 2025

Webrevs

return null;
}
// Construct a new Permission with altPath
// Package private for use by test FilePermissionCollectionMerge
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That test is already calling with reflection and +open, we can just make this private and non-static.

The last use of the original methods were removed when AccessControlContext was functionally removed. If security developers can check, maybe we can just remove these methods completely?

@AlanBateman
Copy link
Contributor

@wangweij Is there any reason to keep the system property jdk.io.permissionsUseCanonicalPath ?

@wangweij
Copy link
Contributor

wangweij commented Apr 13, 2025

I remember the implies method of the file permission class depends on whether this system property is set. Although file permission is no longer used in access control check the class and the method are still there.

@AlanBateman
Copy link
Contributor

AlanBateman commented Apr 14, 2025

I remember the implies method of the file permission class depends on whether this system property is set. Although file permission is no longer used in access control check the class and the method are still there.

Right, and I wasn't suggesting we remove implies(FilePermission), instead I'm wondering if the compatibility knob and the implNote can be removed. As you know, it dates from the change to FilePermission in JDK 9 to do simple path matching rather than canonicalization.

In any case, I don't want to complicate Roger's cleanup, I'm just noting that it's doing cleanup on a compatibility property that we should have removed a few releases/years ago.

@RogerRiggs
Copy link
Contributor Author

I considered dropping the property support, but it seemed harmless to leave it until FilePermission is removed and avoids thrash in an unused implementation and documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org rfr Pull request is ready for review security security-dev@openjdk.org
Development

Successfully merging this pull request may close these issues.

4 participants