Make MAY_CREATE handling more consistent

RESOLVED FIXED in Firefox 66

Status

()

enhancement
P1
normal
RESOLVED FIXED
6 months ago
4 months ago

People

(Reporter: gcp, Assigned: gcp)

Tracking

Trunk
mozilla66
Points:
---

Firefox Tracking Flags

(firefox65 wontfix, firefox66 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

6 months ago
Via Jann Horn:

> MAY_CREATE is required for open() with O_CREAT, but
> not for the target of link() or rename()? That seems inconsistent...

This doesn't currently seem to be a security issue due to the limited amount of paths that have O_WRITE but not O_CREAT, but we should clean it up to prevent it accidentally becoming one.
(Assignee)

Updated

6 months ago
Assignee: nobody → gpascutto
Priority: -- → P1
If we had WebGL and fontconfig remoted, we could just remove support for the affected operations (see also bug 1380701 comment #23) but we don't, yet.
See Also: → 1380701
(Assignee)

Comment 2

6 months ago
Is it consistent that unlink() doesn't require MAY_CREATE?

      case SANDBOX_FILE_UNLINK:
        if (permissive || AllowOperation(W_OK, perms)) {

I think that's a similar bug, right? You can't normally delete a file without access to the parent dir, which would be MAY_CREATE on that in our mappings. I also wonder what the use case would be for deleting files you haven't created, cough.

Comment 5

4 months ago
Pushed by gpascutto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6a7b315a82b2
Make MAY_CREATE handling more consistent. r=jld

Comment 6

4 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
You need to log in before you can comment on or make changes to this bug.