Auditing permissions #59935
Description
What is the problem this feature will solve?
Setting permissions can help protect your resources, but adding these requirements to an existing project can take trial and error as you figure out which permissions you need to grant. Auditing can make this easier.
When a rule is audited, it means it isn't enforced but it is monitored. This allows you to test it without breaking code.
After a user has done an audit, they could see what resources were and weren't accessed and set enforced permissions accordingly.
What is the feature you are proposing to solve the problem?
An "audit mode" could be added to the permissions API to allow permission violations to be logged but not prevented. It could be part of the command-line flag:
--permission=audit --allow-fs-read=.With this configuration, read operations outside the CWD would be logged.
What alternatives have you considered?
One problem with an audit mode is that you cannot both enforce and audit different sets of permissions at the same time. An alternative would be to use separate flags for auditing, kind of like how the Content-Security-Policy-Report-Only HTTP header works.
Say you are currently restricting access to outside write operations but want to test stricter rules. You could do something like this:
--permission --allow-fs-read=* --allow-fs-write=. --audit-permission --audit-allow-fs-read=. --audit-allow-fs-write=dist