The THROW_IF_INSUFFICIENT_PERMISSIONS and
ASYNC_THROW_IF_INSUFFICIENT_PERMISSIONS macros called
ThrowAccessDenied/AsyncThrowAccessDenied unconditionally and only
guarded the `return` with `warning_only()`.
ERR_ACCESS_DENIED_IF_INSUFFICIENT_PERMISSIONS had no `warning_only()`
guard at all — it always set the access-denied error and returned.
As a result, running with `--permission-audit` still produced
ERR_ACCESS_DENIED on any denied operation (fs, net, child_process,
worker, addon, ffi, inspector, wasi), defeating the audit-only purpose
of the flag.

Guard the denied-error path behind `!warning_only()` in all three
macros. In audit mode, the diagnostics-channel message is published
(already done in Permission::is_scope_granted) and execution continues;
in enforce mode (`--permission`), behavior is unchanged — the error is
raised and the call returns.

The tests cover both the direct (top-level) call and an `eval()`-wrapped
call: the direct call exercises the normal script path, and the
`eval()`-wrapped call exercises the V8 script-context boundary (the
diagnostics subscriber is registered in the outer module context while
the denied operation runs inside an eval'd string).

Refs: 9ddd1a9
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: #64426
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

The THROW_IF_INSUFFICIENT_PERMISSIONS and
ASYNC_THROW_IF_INSUFFICIENT_PERMISSIONS macros called
ThrowAccessDenied/AsyncThrowAccessDenied unconditionally and only
guarded the `return` with `warning_only()`.
ERR_ACCESS_DENIED_IF_INSUFFICIENT_PERMISSIONS had no `warning_only()`
guard at all — it always set the access-denied error and returned.
As a result, running with `--permission-audit` still produced
ERR_ACCESS_DENIED on any denied operation (fs, net, child_process,
worker, addon, ffi, inspector, wasi), defeating the audit-only purpose
of the flag.

Guard the denied-error path behind `!warning_only()` in all three
macros. In audit mode, the diagnostics-channel message is published
(already done in Permission::is_scope_granted) and execution continues;
in enforce mode (`--permission`), behavior is unchanged — the error is
raised and the call returns.

The tests cover both the direct (top-level) call and an `eval()`-wrapped
call: the direct call exercises the normal script path, and the
`eval()`-wrapped call exercises the V8 script-context boundary (the
diagnostics subscriber is registered in the outer module context while
the denied operation runs inside an eval'd string).

Refs: 9ddd1a9
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: #64426
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

The THROW_IF_INSUFFICIENT_PERMISSIONS and
ASYNC_THROW_IF_INSUFFICIENT_PERMISSIONS macros called
ThrowAccessDenied/AsyncThrowAccessDenied unconditionally and only
guarded the `return` with `warning_only()`.
ERR_ACCESS_DENIED_IF_INSUFFICIENT_PERMISSIONS had no `warning_only()`
guard at all — it always set the access-denied error and returned.
As a result, running with `--permission-audit` still produced
ERR_ACCESS_DENIED on any denied operation (fs, net, child_process,
worker, addon, ffi, inspector, wasi), defeating the audit-only purpose
of the flag.

Guard the denied-error path behind `!warning_only()` in all three
macros. In audit mode, the diagnostics-channel message is published
(already done in Permission::is_scope_granted) and execution continues;
in enforce mode (`--permission`), behavior is unchanged — the error is
raised and the call returns.

The tests cover both the direct (top-level) call and an `eval()`-wrapped
call: the direct call exercises the normal script path, and the
`eval()`-wrapped call exercises the V8 script-context boundary (the
diagnostics subscriber is registered in the outer module context while
the denied operation runs inside an eval'd string).

Refs: 9ddd1a9
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: #64426
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

Expand the documentation for the --permission-audit flag, which was
fixed in 51c09ea to no longer throw ERR_ACCESS_DENIED on denied
operations. The previous docs only had a two-sentence description in
cli.md and no mention in the permissions guide or process.permission
API docs.

- permissions.md: add enforce vs audit mode overview, a new
  "Audit Mode" subsection listing the diagnostics channel names
  (node:permission-model:*) and the { permission, resource } message
  shape, and a usage example. Update the Runtime API section to
  mention both --permission and --permission-audit.
- cli.md: expand the --permission-audit section to clarify that
  --permission is not required, --allow-* flags are not needed,
  errors are not thrown, and --permission takes precedence when both
  are set. Add a cross-reference from --permission to
  --permission-audit.
- process.md: note that process.permission is available under both
  flags, and clarify permission.has() and permission.drop() behavior
  in audit mode.
- node.1: regenerated via `make node.1`.

Refs: nodejs#64426
PR-URL: nodejs#64791
Signed-off-by: Adrian Estrada <edsadr@gmail.com>

The THROW_IF_INSUFFICIENT_PERMISSIONS and
ASYNC_THROW_IF_INSUFFICIENT_PERMISSIONS macros called
ThrowAccessDenied/AsyncThrowAccessDenied unconditionally and only
guarded the `return` with `warning_only()`.
ERR_ACCESS_DENIED_IF_INSUFFICIENT_PERMISSIONS had no `warning_only()`
guard at all — it always set the access-denied error and returned.
As a result, running with `--permission-audit` still produced
ERR_ACCESS_DENIED on any denied operation (fs, net, child_process,
worker, addon, ffi, inspector, wasi), defeating the audit-only purpose
of the flag.

Guard the denied-error path behind `!warning_only()` in all three
macros. In audit mode, the diagnostics-channel message is published
(already done in Permission::is_scope_granted) and execution continues;
in enforce mode (`--permission`), behavior is unchanged — the error is
raised and the call returns.

The tests cover both the direct (top-level) call and an `eval()`-wrapped
call: the direct call exercises the normal script path, and the
`eval()`-wrapped call exercises the V8 script-context boundary (the
diagnostics subscriber is registered in the outer module context while
the denied operation runs inside an eval'd string).

Refs: 9ddd1a9
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: #64426
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

Expand the documentation for the --permission-audit flag, which was
fixed in 51c09ea to no longer throw ERR_ACCESS_DENIED on denied
operations. The previous docs only had a two-sentence description in
cli.md and no mention in the permissions guide or process.permission
API docs.

- permissions.md: add enforce vs audit mode overview, a new
  "Audit Mode" subsection listing the diagnostics channel names
  (node:permission-model:*) and the { permission, resource } message
  shape, and a usage example. Update the Runtime API section to
  mention both --permission and --permission-audit.
- cli.md: expand the --permission-audit section to clarify that
  --permission is not required, --allow-* flags are not needed,
  errors are not thrown, and --permission takes precedence when both
  are set. Add a cross-reference from --permission to
  --permission-audit.
- process.md: note that process.permission is available under both
  flags, and clarify permission.has() and permission.drop() behavior
  in audit mode.
- node.1: regenerated via `make node.1`.

Refs: #64426
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: #64791
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

Expand the documentation for the --permission-audit flag, which was
fixed in 51c09ea to no longer throw ERR_ACCESS_DENIED on denied
operations. The previous docs only had a two-sentence description in
cli.md and no mention in the permissions guide or process.permission
API docs.

- permissions.md: add enforce vs audit mode overview, a new
  "Audit Mode" subsection listing the diagnostics channel names
  (node:permission-model:*) and the { permission, resource } message
  shape, and a usage example. Update the Runtime API section to
  mention both --permission and --permission-audit.
- cli.md: expand the --permission-audit section to clarify that
  --permission is not required, --allow-* flags are not needed,
  errors are not thrown, and --permission takes precedence when both
  are set. Add a cross-reference from --permission to
  --permission-audit.
- process.md: note that process.permission is available under both
  flags, and clarify permission.has() and permission.drop() behavior
  in audit mode.
- node.1: regenerated via `make node.1`.

Refs: #64426
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: #64791
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

Expand the documentation for the --permission-audit flag, which was
fixed in 51c09ea to no longer throw ERR_ACCESS_DENIED on denied
operations. The previous docs only had a two-sentence description in
cli.md and no mention in the permissions guide or process.permission
API docs.

- permissions.md: add enforce vs audit mode overview, a new
  "Audit Mode" subsection listing the diagnostics channel names
  (node:permission-model:*) and the { permission, resource } message
  shape, and a usage example. Update the Runtime API section to
  mention both --permission and --permission-audit.
- cli.md: expand the --permission-audit section to clarify that
  --permission is not required, --allow-* flags are not needed,
  errors are not thrown, and --permission takes precedence when both
  are set. Add a cross-reference from --permission to
  --permission-audit.
- process.md: note that process.permission is available under both
  flags, and clarify permission.has() and permission.drop() behavior
  in audit mode.
- node.1: regenerated via `make node.1`.

Refs: #64426
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: #64791
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

Expand the documentation for the --permission-audit flag, which was
fixed in 51c09ea to no longer throw ERR_ACCESS_DENIED on denied
operations. The previous docs only had a two-sentence description in
cli.md and no mention in the permissions guide or process.permission
API docs.

- permissions.md: add enforce vs audit mode overview, a new
  "Audit Mode" subsection listing the diagnostics channel names
  (node:permission-model:*) and the { permission, resource } message
  shape, and a usage example. Update the Runtime API section to
  mention both --permission and --permission-audit.
- cli.md: expand the --permission-audit section to clarify that
  --permission is not required, --allow-* flags are not needed,
  errors are not thrown, and --permission takes precedence when both
  are set. Add a cross-reference from --permission to
  --permission-audit.
- process.md: note that process.permission is available under both
  flags, and clarify permission.has() and permission.drop() behavior
  in audit mode.
- node.1: regenerated via `make node.1`.

Refs: #64426
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: #64791
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

The THROW_IF_INSUFFICIENT_PERMISSIONS and
ASYNC_THROW_IF_INSUFFICIENT_PERMISSIONS macros called
ThrowAccessDenied/AsyncThrowAccessDenied unconditionally and only
guarded the `return` with `warning_only()`.
ERR_ACCESS_DENIED_IF_INSUFFICIENT_PERMISSIONS had no `warning_only()`
guard at all — it always set the access-denied error and returned.
As a result, running with `--permission-audit` still produced
ERR_ACCESS_DENIED on any denied operation (fs, net, child_process,
worker, addon, ffi, inspector, wasi), defeating the audit-only purpose
of the flag.

Guard the denied-error path behind `!warning_only()` in all three
macros. In audit mode, the diagnostics-channel message is published
(already done in Permission::is_scope_granted) and execution continues;
in enforce mode (`--permission`), behavior is unchanged — the error is
raised and the call returns.

The tests cover both the direct (top-level) call and an `eval()`-wrapped
call: the direct call exercises the normal script path, and the
`eval()`-wrapped call exercises the V8 script-context boundary (the
diagnostics subscriber is registered in the outer module context while
the denied operation runs inside an eval'd string).

Refs: nodejs@9ddd1a9
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: nodejs#64426
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

Expand the documentation for the --permission-audit flag, which was
fixed in 51c09ea to no longer throw ERR_ACCESS_DENIED on denied
operations. The previous docs only had a two-sentence description in
cli.md and no mention in the permissions guide or process.permission
API docs.

- permissions.md: add enforce vs audit mode overview, a new
  "Audit Mode" subsection listing the diagnostics channel names
  (node:permission-model:*) and the { permission, resource } message
  shape, and a usage example. Update the Runtime API section to
  mention both --permission and --permission-audit.
- cli.md: expand the --permission-audit section to clarify that
  --permission is not required, --allow-* flags are not needed,
  errors are not thrown, and --permission takes precedence when both
  are set. Add a cross-reference from --permission to
  --permission-audit.
- process.md: note that process.permission is available under both
  flags, and clarify permission.has() and permission.drop() behavior
  in audit mode.
- node.1: regenerated via `make node.1`.

Refs: nodejs#64426
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: nodejs#64791
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

The THROW_IF_INSUFFICIENT_PERMISSIONS and
ASYNC_THROW_IF_INSUFFICIENT_PERMISSIONS macros called
ThrowAccessDenied/AsyncThrowAccessDenied unconditionally and only
guarded the `return` with `warning_only()`.
ERR_ACCESS_DENIED_IF_INSUFFICIENT_PERMISSIONS had no `warning_only()`
guard at all — it always set the access-denied error and returned.
As a result, running with `--permission-audit` still produced
ERR_ACCESS_DENIED on any denied operation (fs, net, child_process,
worker, addon, ffi, inspector, wasi), defeating the audit-only purpose
of the flag.

Guard the denied-error path behind `!warning_only()` in all three
macros. In audit mode, the diagnostics-channel message is published
(already done in Permission::is_scope_granted) and execution continues;
in enforce mode (`--permission`), behavior is unchanged — the error is
raised and the call returns.

The tests cover both the direct (top-level) call and an `eval()`-wrapped
call: the direct call exercises the normal script path, and the
`eval()`-wrapped call exercises the V8 script-context boundary (the
diagnostics subscriber is registered in the outer module context while
the denied operation runs inside an eval'd string).

Refs: nodejs@9ddd1a9
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: nodejs#64426
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

Expand the documentation for the --permission-audit flag, which was
fixed in 51c09ea to no longer throw ERR_ACCESS_DENIED on denied
operations. The previous docs only had a two-sentence description in
cli.md and no mention in the permissions guide or process.permission
API docs.

- permissions.md: add enforce vs audit mode overview, a new
  "Audit Mode" subsection listing the diagnostics channel names
  (node:permission-model:*) and the { permission, resource } message
  shape, and a usage example. Update the Runtime API section to
  mention both --permission and --permission-audit.
- cli.md: expand the --permission-audit section to clarify that
  --permission is not required, --allow-* flags are not needed,
  errors are not thrown, and --permission takes precedence when both
  are set. Add a cross-reference from --permission to
  --permission-audit.
- process.md: note that process.permission is available under both
  flags, and clarify permission.has() and permission.drop() behavior
  in audit mode.
- node.1: regenerated via `make node.1`.

Refs: nodejs#64426
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: nodejs#64791
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

The THROW_IF_INSUFFICIENT_PERMISSIONS and
ASYNC_THROW_IF_INSUFFICIENT_PERMISSIONS macros called
ThrowAccessDenied/AsyncThrowAccessDenied unconditionally and only
guarded the `return` with `warning_only()`.
ERR_ACCESS_DENIED_IF_INSUFFICIENT_PERMISSIONS had no `warning_only()`
guard at all — it always set the access-denied error and returned.
As a result, running with `--permission-audit` still produced
ERR_ACCESS_DENIED on any denied operation (fs, net, child_process,
worker, addon, ffi, inspector, wasi), defeating the audit-only purpose
of the flag.

Guard the denied-error path behind `!warning_only()` in all three
macros. In audit mode, the diagnostics-channel message is published
(already done in Permission::is_scope_granted) and execution continues;
in enforce mode (`--permission`), behavior is unchanged — the error is
raised and the call returns.

The tests cover both the direct (top-level) call and an `eval()`-wrapped
call: the direct call exercises the normal script path, and the
`eval()`-wrapped call exercises the V8 script-context boundary (the
diagnostics subscriber is registered in the outer module context while
the denied operation runs inside an eval'd string).

Refs: 9ddd1a9
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: #64426
Backport-PR-URL: #65354
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>

Expand the documentation for the --permission-audit flag, which was
fixed in 51c09ea to no longer throw ERR_ACCESS_DENIED on denied
operations. The previous docs only had a two-sentence description in
cli.md and no mention in the permissions guide or process.permission
API docs.

- permissions.md: add enforce vs audit mode overview, a new
  "Audit Mode" subsection listing the diagnostics channel names
  (node:permission-model:*) and the { permission, resource } message
  shape, and a usage example. Update the Runtime API section to
  mention both --permission and --permission-audit.
- cli.md: expand the --permission-audit section to clarify that
  --permission is not required, --allow-* flags are not needed,
  errors are not thrown, and --permission takes precedence when both
  are set. Add a cross-reference from --permission to
  --permission-audit.
- process.md: note that process.permission is available under both
  flags, and clarify permission.has() and permission.drop() behavior
  in audit mode.
- node.1: regenerated via `make node.1`.

Refs: #64426
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: #64791
Backport-PR-URL: #65354
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>