Skip to content

Conversation

@prdoyle
Copy link
Contributor

@prdoyle prdoyle commented Dec 9, 2025

In entitlements, we currently catch and swallow IOException encountered during a read check of a symlink. This is necessary because an IOException is how the Java API tells us that permission has been denied.

The trouble is, if other IOExceptions happen, like weird filesystem situations, we discard that information and simply report that permission is denied, which can be confusing.

Let's include a little bit of info about why the permission was denied.

@prdoyle prdoyle self-assigned this Dec 9, 2025
@prdoyle prdoyle requested a review from a team as a code owner December 9, 2025 21:42
@elasticsearchmachine elasticsearchmachine added the Team:Core/Infra Meta label for core/infra team label Dec 9, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

throw e; // rethrow
} catch (IOException e) {
canRead = false;
denialReason = e.toString();
Copy link
Member

Choose a reason for hiding this comment

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

rather than wrap this as an entitlement error, why not widen the NoSuchFileException above to IOException? ie just rethrow any IOException. This would allow the caller to act (eg by retrying the operation if it knows it's a network file system). This really shouldn't be an entitlement error, it's a filesystem error that is getting confused for an entitlement problem.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants