Skip to documentation
quickS3.comOpen app
Browse documentation
Access

How allow and deny rules work

What an allow or deny rule is made of, how rules from several roles combine, and why a deny always wins no matter which role it came from.

OwnerAdmin

A role is a list of rules. Each rule is one row in the role editor:

Column What it does
Effect Allow grants access. Deny takes it away.
Connection Which storage connection the rule is about.
Bucket Which bucket on that connection.
Prefix Which folder in the bucket, like reports/. Leave it empty for the whole bucket.
Read, Write, Delete What the rule allows or denies. Choose any combination.

Read covers browsing, previewing, and downloading. Write covers uploading, overwriting, and creating folders. Delete covers deleting files and empty folders. Share covers creating public links, together with Read (download links) or Write (file requests). Read, Write, Delete, and Share has the full list.

How quickS3 decides

For every action someone takes, quickS3 looks at all the rules in all of their roles:

  1. If any Deny rule matches, the answer is no.
  2. Otherwise, if any Allow rule matches, the answer is yes.
  3. If nothing matches, the answer is no.

That’s the whole logic. The order of rules and roles doesn’t matter, and a more specific rule doesn’t beat a broader one. Nobody has access to anything until a rule allows it.

Owners skip this check. They can reach everything on every connection, which is why you should test new roles with someone who isn’t an Owner.

Why deny always wins

Once you add a Deny rule, you can trust it: no Allow in any other role will reopen that folder by accident. The price is that you can’t carve an exception back out of a Deny. To let someone into part of a denied folder, narrow the Deny instead.

The role editor helps you spot conflicts. A rule marked “A deny rule cancels at least one action granted here” is being overridden by a Deny in the same role.

How prefixes match

A prefix covers that folder and everything inside it.

  • reports/ matches reports/q1.pdf and reports/2026/q1.pdf.
  • reports/ does not match reports-old/q1.pdf. Prefixes always stop at a /.
  • Slashes at the start or end don’t matter: reports, /reports, and reports/ are the same rule.
  • Prefixes are case-sensitive: Reports/ and reports/ are different folders.

Bucket names aren’t case-sensitive, but a rule only ever applies to its own connection. A rule for the assets bucket on one connection says nothing about an assets bucket on another.

An example

A role with these two rules:

Effect Bucket Prefix Read Write Delete
Allow projects incoming/ ✓ ✓ ✓
Deny projects incoming/private/ ✓ ✓ ✓

The person can work anywhere in incoming/, including making new folders there. incoming/private/ doesn’t appear in their file list at all, and opening it directly is refused.

For more patterns like this, see folder access recipes.