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

fix: remove --allow-run warning when using deno without args or subcommand #25684

Conversation

HasanAlrimawi
Copy link
Contributor

This PR addresses issue #25676

Approach
Don't warn when no args deno is used. [command typed as deno]

Changes

  • A check was added before warning about the allow-run.
  • Given that no_args_deno is dealt with as a deno repl. The check is to see if the subcommand is a repl command with the is_default_command property true, if yes, then this is a no_args_deno and there's no need to warn.
  • If it's not no_args_deno and the allow-run flag is found, then the warning is shown.

Issue root-cause
when using no_args_deno (invoking deno with no args or subcommands), then all of the allow-* flags are set by default which caused the warning to get triggered because there's no allow-run-list specified with it.

cli/args/mod.rs Outdated
};
// discourage using --allow-run without an allow list, but
// allow it when no args deno is used [deno] without subcommand
if allow_run_list.is_empty() && !is_no_args_deno {
Copy link
Member

@dsherret dsherret Sep 17, 2024

Choose a reason for hiding this comment

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

I think we should change this to instead set flags.permissions.allow_all = true;:

deno/cli/args/flags.rs

Lines 1370 to 1376 in f360cae

flags.permissions.allow_net = Some(vec![]);
flags.permissions.allow_env = Some(vec![]);
flags.permissions.allow_run = Some(vec![]);
flags.permissions.allow_read = Some(vec![]);
flags.permissions.allow_sys = Some(vec![]);
flags.permissions.allow_write = Some(vec![]);
flags.permissions.allow_ffi = Some(vec![]);

Copy link
Member

Choose a reason for hiding this comment

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

There's actually a flags.allow_all(); and I think internally that should just set flags.permissions.allow_all = true only.

Copy link
Member

@dsherret dsherret left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks!

@dsherret dsherret enabled auto-merge (squash) September 18, 2024 12:36
@dsherret
Copy link
Member

I broke this. Looking into it.

@dsherret dsherret disabled auto-merge September 18, 2024 14:14
@HasanAlrimawi
Copy link
Contributor Author

HasanAlrimawi commented Sep 18, 2024

I tried to investigate it:
Mainly, I believe whenever allow-all is set, it should allow access for everything except if there's specific deny flag.
Maybe the issue lies within permission granting logic, I suspect the fix might be somewhere in cli/runtime/permissions/lib.rs, as your changes seem logical (allow all has high priority and there's no need to set other allow flags to Some(vec![]) and the logic should be good with them cleared as None)

I noticed you made a new commit to fix the issue, but let me ask you to take a look at fn is_allow_all() in cli/runtime/permissions/lib.rs. Does it need to check if the allow-all flag is set to true at some point and if yes then does it do that.
The function name seems to convey this idea.

Edit: No need, all checks have passed

Copy link
Member

@bartlomieju bartlomieju left a comment

Choose a reason for hiding this comment

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

LGTM

@bartlomieju bartlomieju merged commit 49a0b7a into denoland:main Sep 18, 2024
17 checks passed
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.

3 participants