I filed bug 930258 with the open()s I knew about on B2G. There's a lot of file opening going on presently. At one point I tried having the whitelist inspect the flags and allow read-only opens, to see how hard it would be to tighten the whitelist gradually; that failed because of something (MediaCache, maybe?) creating temporary files. I then tried allowing either read-only or O_RDWR|O_EXCL|O_CREAT, but that failed on device-specific graphics libraries opening a device O_RDWR. That said, attachment 828975 [details] looks like something is trying to open a file read-only to load code of some sort. I don't know exactly what's going on here, but it looks similar to the use case for PRemoteOpenFile (netwerk/ipc/PRemoteOpenFile.ipdl), which has a bunch of access control in NeckoParent::AllocPRemoteOpenFileParent. Currently it's limited to the application.zip files of web apps that that child should need to access, from my cursory reading of it, but if there are other files we read on desktop then it might make sense to extend it.
re: comment 1. Yes, PRemoteFileOpen should work well for read-only file access. Of course we'll have to change open() calls to an async model where they start the open and are notified when it's done, and we'll need to expand permissions beyond application.zip. But the infrastructure is there. It could also be extended to write access, fstat, and/or unlink too.
Move process sandboxing bugs to the new Bugzilla component. (Sorry for the bugspam; filter on 3c21328c-8cfb-4819-9d88-f6e965067350.)
Component: Security → Security: Process Sandboxing
Moving to sblc3 which should conclude the removing/restricting of file system access.
Whiteboard: sblc2 → sblc3
fixed by file broker.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.