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

Don't ever claim /dev/null is an execpath. #12516

Closed
wants to merge 1 commit into from

Conversation

benjaminp
Copy link
Collaborator

SpawnInputExpander.EMPTY_FILE claimed an execpath of /dev/null, which could lead to clients trying to do mutating filesystem operations in /dev.

In this change, SpawnInputExpander.EMPTY_FILE is replaced with an EmptyVirtualInput with no execpath. This way errant callers will explode before trying filesystem operations on it. Such a EmptyVirtualInput doesn't really meet the contract of being an ActionInput but that was really already true.

@google-cla google-cla bot added the cla: yes label Nov 19, 2020
@benjaminp
Copy link
Collaborator Author

This is a cleanup related to #12514 but split out because it might break blaze due to fileset things I can't see.

@benjaminp benjaminp force-pushed the empty-virtual branch 2 times, most recently from 633accd to 507a47e Compare November 23, 2020 14:12
@Nullable private final PathFragment execPath;

private EmptyActionInput() {
execPath = null;
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of setting the field to null and handling that case in all of the methods, it would be easier to just have a private class for the empty marker singleton.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, that sounds better. I didn't know if this was the only use of EmptyActionInput or if some Google code makes real execpath empty inputs.

Copy link
Contributor

Choose a reason for hiding this comment

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

There is one internal use of EmptyActionInput that also passes /dev/null. I suggest keeping this class as it was for now and just create a new VirtualActionInput implementation class for the "null" case. I will separately see if the internal use case can be migrated similarly and if so follow up with a change to delete this class.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Okay, reverting to the original version of the PR now...

@benjaminp benjaminp force-pushed the empty-virtual branch 2 times, most recently from 8ba61cb to 507a47e Compare November 25, 2020 14:50
SpawnInputExpander.EMPTY_FILE claimed an execpath of /dev/null, which could lead to clients trying to do mutating filesystem operations in /dev.

In this change, SpawnInputExpander.EMPTY_FILE is replaced with an EmptyVirtualInput with no execpath. This way errant callers will explode before trying filesystem operations on it. Such a EmptyVirtualInput doesn't really meet the contract of being an ActionInput but that was really already true.
@aiuto
Copy link
Contributor

aiuto commented Jan 6, 2021

@justinhorvitz sending you the import CL. I'm on triage duty this week and trying to clean the backlog of stale PRs.

@bazel-io bazel-io closed this in ceec93c Jan 6, 2021
@benjaminp benjaminp deleted the empty-virtual branch January 6, 2021 23:21
@aiuto
Copy link
Contributor

aiuto commented Jan 8, 2021

Had to roll this back. I'm working on relanding it. 0f626a4

bazel-io pushed a commit that referenced this pull request Jan 12, 2021
SpawnInputExpander.EMPTY_FILE claimed an execpath of /dev/null, which could lead to clients trying to do mutating filesystem operations in /dev.

In this change, SpawnInputExpander.EMPTY_FILE is replaced with an EmptyVirtualInput with no execpath. This way errant callers will explode before trying filesystem operations on it. Such a EmptyVirtualInput doesn't really meet the contract of being an ActionInput but that was really already true.

Closes #12516.

Roll forward of ceec93c,
which was rolled back in 0f626a4

RELNOTES: None.
PiperOrigin-RevId: 351367453
@benjaminp
Copy link
Collaborator Author

Thank you for sorting that out.

@aiuto
Copy link
Contributor

aiuto commented Jan 13, 2021

You're welcome. I forgot, however, to munge the re-landing to give the attribution to you. Sorry about that. It's a pity the tooling does not do this automatically.

coeuvre pushed a commit to coeuvre/bazel that referenced this pull request Jul 15, 2021
SpawnInputExpander.EMPTY_FILE claimed an execpath of /dev/null, which could lead to clients trying to do mutating filesystem operations in /dev.

In this change, SpawnInputExpander.EMPTY_FILE is replaced with an EmptyVirtualInput with no execpath. This way errant callers will explode before trying filesystem operations on it. Such a EmptyVirtualInput doesn't really meet the contract of being an ActionInput but that was really already true.

Closes bazelbuild#12516.

Roll forward of ceec93c,
which was rolled back in 0f626a4

RELNOTES: None.
PiperOrigin-RevId: 351367453
coeuvre pushed a commit to coeuvre/bazel that referenced this pull request Jul 16, 2021
SpawnInputExpander.EMPTY_FILE claimed an execpath of /dev/null, which could lead to clients trying to do mutating filesystem operations in /dev.

In this change, SpawnInputExpander.EMPTY_FILE is replaced with an EmptyVirtualInput with no execpath. This way errant callers will explode before trying filesystem operations on it. Such a EmptyVirtualInput doesn't really meet the contract of being an ActionInput but that was really already true.

Closes bazelbuild#12516.

Roll forward of ceec93c,
which was rolled back in 0f626a4

RELNOTES: None.
PiperOrigin-RevId: 351367453
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