Disallow links from being seen by the extensions via the fileapi.

Disallow links from being seen by the extensions via the fileapi.
This change is more of a hack at the moment, ideally we need to refactor file_util (and maybe a bit of file_path) to provide better ways to handle symlinks.
This fix prevents exploits reading arbitary files either through handled extension calls or our component extension.

BUG=chromium-os:15826
TEST=Verified that links do not show up when reading a directory in the file browser UI. Tests that specifically check for this will follow in subsequent checkins.

[Evan Martin, 2011-05-27 19:04:37]

Why check in hacks?  Why not fix this properly?

[Evan Martin, 2011-05-27 19:05:46]

On 2011/05/27 19:04:37, Evan Martin wrote:
> Why check in hacks?  Why not fix this properly?

Can you CC me on the cros bug?  I can't view it right now.

[Evan Martin, 2011-05-27 20:57:09]

http://codereview.chromium.org/7085005/diff/5/webkit/fileapi/file_system_file...
File webkit/fileapi/file_system_file_util.cc (right):

http://codereview.chromium.org/7085005/diff/5/webkit/fileapi/file_system_file...
webkit/fileapi/file_system_file_util.cc:87: if (file_util::IsLink(file_path))
Can you make this function local to this file?  That is, don't extend file_api?

[Evan Martin, 2011-05-27 21:02:53]

Or maybe better, just remove the OS_CHROMEOS bits?  I think it'd be safer to
just ignore symlinks in general until we have a known use case for them.

[Evan Martin, 2011-05-27 21:17:48]

On 2011/05/27 21:02:53, Evan Martin wrote:
> Or maybe better, just remove the OS_CHROMEOS bits?  I think it'd be safer to
> just ignore symlinks in general until we have a known use case for them.

OK, having talked with some people, I suggest:
1) make the file_util function a no-op that returns false on Windows, but
implemented for POSIX
2) remove all the OS_CHROMEOS bits

[rkc, 2011-05-31 21:20:14]

Done.

On 2011/05/27 21:17:48, Evan Martin wrote:
> On 2011/05/27 21:02:53, Evan Martin wrote:
> > Or maybe better, just remove the OS_CHROMEOS bits?  I think it'd be safer to
> > just ignore symlinks in general until we have a known use case for them.
> 
> OK, having talked with some people, I suggest:
> 1) make the file_util function a no-op that returns false on Windows, but
> implemented for POSIX
> 2) remove all the OS_CHROMEOS bits

[Evan Martin, 2011-05-31 21:22:32]

I hate to be a stickler, but would you mind ending your comments with periods? 
(I promise I'm a fast reviewer)

http://codereview.chromium.org/7085005/diff/5007/base/file_util_win.cc
File base/file_util_win.cc (right):

http://codereview.chromium.org/7085005/diff/5007/base/file_util_win.cc#newcod...
base/file_util_win.cc:705: // No symlinks on windows
This isn't quite true -- NTFS supports junctions:
http://en.wikipedia.org/wiki/NTFS_junction_point

I'd just put in a TODO: should we test for junctions here?

http://codereview.chromium.org/7085005/diff/5007/webkit/fileapi/file_system_f...
File webkit/fileapi/file_system_file_util.cc (right):

http://codereview.chromium.org/7085005/diff/5007/webkit/fileapi/file_system_f...
webkit/fileapi/file_system_file_util.cc:85: // links
Can you describe how this is a hack?  Or link to a bug number?

http://codereview.chromium.org/7085005/diff/5007/webkit/fileapi/file_system_f...
webkit/fileapi/file_system_file_util.cc:119: entries->push_back(entry);
tabbing wrong here.

[rkc, 2011-05-31 21:49:56]

Review comments incorporated.

http://codereview.chromium.org/7085005/diff/5007/base/file_util_win.cc
File base/file_util_win.cc (right):

http://codereview.chromium.org/7085005/diff/5007/base/file_util_win.cc#newcod...
base/file_util_win.cc:705: // No symlinks on windows
Done.
On 2011/05/31 21:22:32, Evan Martin wrote:
> This isn't quite true -- NTFS supports junctions:
> http://en.wikipedia.org/wiki/NTFS_junction_point
> 
> I'd just put in a TODO: should we test for junctions here?

http://codereview.chromium.org/7085005/diff/5007/webkit/fileapi/file_system_f...
File webkit/fileapi/file_system_file_util.cc (right):

http://codereview.chromium.org/7085005/diff/5007/webkit/fileapi/file_system_f...
webkit/fileapi/file_system_file_util.cc:85: // links
On 2011/05/31 21:22:32, Evan Martin wrote:
> Can you describe how this is a hack?  Or link to a bug number?

Done.

http://codereview.chromium.org/7085005/diff/5007/webkit/fileapi/file_system_f...
webkit/fileapi/file_system_file_util.cc:119: entries->push_back(entry);
On 2011/05/31 21:22:32, Evan Martin wrote:
> tabbing wrong here.

Done.

[Evan Martin, 2011-05-31 23:00:12]

LGTM, thank you for putting up with my nit-picking!

http://codereview.chromium.org/7085005/diff/5009/base/file_util_posix.cc
File base/file_util_posix.cc (right):

http://codereview.chromium.org/7085005/diff/5009/base/file_util_posix.cc#newc...
base/file_util_posix.cc:530: // least be a 'followable' link
period