According to the permission of sdcard folder is (system sdcard_rw), content process doesn't have permission to create/delete/write files. So current implementation is that content process accessed files (via Device Storage API) via IPC for asking Chrome process as a proxy to do actions. This will downgrade the performance of file r/w. Maybe we can add UID of an App with right permission into group of sdcard_rw, so content process can access files directly.
Note, allowing arbitrary content processes to read the sdcard is against our security model. Allowing that would let compromised processes read user data. In the current implementation, when a content process with "mediastorage" permissions wants to read or write a file, it does the following 1. Proxy a request for a file to the main process 2. The main process applies security checks, and if they pass, open()s an fd and sendmsg(SCM_RIGHTS) the fd to the content process 3. From there on, a content process can read()/write() the fd as if the process had opened the fd itself. It's not clear what data is motivating filing this bug. Can you share a testcase or performance report?
http://mxr.mozilla.org/mozilla-central/source/dom/devicestorage/nsDeviceStorage.cpp#1585 I saw the code as above for device storage API will route all of commands to Chrome process not done by content process. So just fire this bug.
Right, that call should be requesting an fd from the master process (which will apply the appropriate permissions checks before returning it). Let's confirm that's what's happening.
Yes, that should be what is happening. The parent process will create a Blob object which is then sent to the child process. Once the child process starts reading from the Blob we send a message to the Blob in the parent process which then opens the file and sends a cloned fd to the child process. The child process then uses this fd to read the contents of the file.
Thanks for all of your clarification. Q1: Even though commands from DeviceStorage still route to Chrome process (at least create & delete files). One of performance testing is a. create file b. write 1k bytes c. delete file d. do 1000 or more times from a ~ c. In such test case, we will spend additional time for IPC between Chrome and Content process. (IPC for creating file and waiting for clone fd) Q2: If some one create a remote Blob from content process and call a function with mutex in other thread which will check the setup of remoteInputStream in Blob. In the following main thread call a function with the same mutex for closing Blob. Then dead lock occurred because main thread can't receive the event for remoteInputStream setup. Please refer to Bug 823445. Q3: How about writing data into file? Even content process has the clone fd from Chrome, does it have permission to write data into /sdcard (system sdcard_rw)? Many thanks for all your reply in advance.
There is no doubt that the extra IPC here is costing performance-wise. I.e. if we didn't have to worry about security we would certainly write the code in a different way which would be faster. Security often causes longer codepaths to be taken. However that isn't a problem unless that cost is high. We shouldn't be worried here unless we have data indicating that the overhead is high enough that the user notices slowdown. I can't give any exact numbers for how much performance overhead we're willing to pay, I think that's a matter of discussion. If you are concerned that the current solution is too slow, getting numbers actual numbers that we can compare and discuss would be the first step.
(In reply to Marco Chen [:mchen] Away from 12/29 ~ 1/6 from comment #5) > Thanks for all of your clarification. > > Q1: Even though commands from DeviceStorage still route to Chrome process > (at least create & delete files). One of performance testing is > a. create file > b. write 1k bytes > c. delete file > d. do 1000 or more times from a ~ c. > In such test case, we will spend additional time for IPC between Chrome and > Content process. (IPC for creating file and waiting for clone fd) Note, unless this test is fsync()ing the data you're writing, it's not very meaningful. Are you sure the data is being flushed to disk? There's definitely overhead to IPC, but it's a few orders of magnitude lower than uncached disk operations. What real-world workload do you expect this test to simulate? > Q3: How about writing data into file? Even content process has the clone fd > from Chrome, does it have permission to write data into /sdcard (system > sdcard_rw)? Did your test in Q1 answer this question? The b2g process opens the file "r" or "rw" as appropriate and then dup()s the fd to the content process. The content process can use that fd even though it can't directly open or stat the underlying file. This is a well-known UNIX trick.
Note that we currently don't have use-cases which involves the child process opening a file from the SD card and then writes to it. Well.. we have use-cases, but none that we are aiming to solve for v1. The only APIs that we are supporting in v1 which allows writing to the sdcard is by using the DeviceStorage.add function. This function takes a blob object and a name. The way that function is implemented is that we send the Blob from the child process to the parent process. The parent process then opens the file (removing the old file if one exists), reads from the Blob and then writes to the file. In future versions we'll add support for the FileHandle API which will allow a child process to open a file and then write anywhere in the file. But there's no code to support that right now.
Hi all, Thanks for your explanation, and due to I am on vocation now I can't give you response in time. I am still interest on the implementation of deviceStorage/blob/file. Because I found that 1. nsIDeviceStorage::add(...) only tried to create and |write| data into file on Chrome Process. http://dxr.mozilla.org/mozilla-central/dom/devicestorage/nsDeviceStorage.cpp.html#l1561 2. Then WriteFileEvent::Run() is performed in Chrome process. http://dxr.mozilla.org/mozilla-central/dom/devicestorage/nsDeviceStorage.cpp.html#l1287 3. The RemoteInputStream is used to transfer data between BlobParent and BlobChild. So it seems to be used to on step above for getting data from content process then writing to file in Chrome process. Maybe my understanding is wrong, please let me to figure out it. Thanks.
I tested it with two cases. 1. Writing 1000 files with 1k bytes. 2. Writing 10 files with 1M bytes. I add test code into Gallery App and test it with OOP and non-OOP cases. The results are no obviously different between OOP and non-OOP. Case 1: about 90 seconds Case 2: about 15 seconds.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.