[Webkit-unassigned] [Bug 45864] Add HRTFElevation files

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=45864





--- Comment #5 from Simon Fraser (smfr) <simon.fraser at apple.com>  2010-09-16 17:20:58 PST ---
> > WebCore/platform/audio/HRTFElevation.cpp:122
> > +    snprintf(filePath, sizeof(filePath), "%s/IRC_%s_C_R0195_T%03d_P%03d.aif", hrirSubDirectory, subjectName, azimuth, positiveElevation);
> 
> Yuck :(.  What's the plan for improving this?
> 
> 
> Yeah, I know... For sandboxing reasons I understand that Chrome can't read directly from the file system (and probably WebKit2 will have a similar problem).
> The long-term goal is to create an audio-file resource abstraction.  In a sandboxed implementation it could get the file data into the renderer process via shared memory.
> Even once the code is changed to use this abstraction I suspect there will still be a similar type of snprintf (or equivalent) in order to construct the audio resource name.
> 
> Migrating to this resource abstraction must happen before it will be able to run in sandboxed Chrome, so there's little chance of this falling through the cracks.
> In the meantime, during bringup of this code in WebKit trunk, it's essential to have this simpler code working in order to exercise and test that all of the other parts of the code
> are working correctly.
> 
> I'll put a FIXME here to describe this situation.  But much of this code will still remain the same here since the createBusFromAudioFile() function I'm
> currently using can access this abstraction.

This worries me. Any new access to the filesystem could potentially open a huge security hole. I think you need to disable this feature until the issue is resolved.

Do you expect browser vendors to ship a bunch of new resource files? If so, where are they?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.