Issue metadata
Sign in to add a comment
|
Allow opening accessible files in the container with Chrome |
||||||||||||||||||||||||
Issue descriptionNow that we have mounting of the container's home directory in the Files app, we should be able to allow Chrome to open items that have a file:// URL in the container via the command line in the container (i.e. xdg-open foo.pdf) Currently we reject any URLs that come in with a file:// argument for security reasons. We should be able to see that it's in the user's home dir (if it's not, we can't do it), and then modify it to be the locally mounted path instead. I would want security's blessing before doing this though.
,
Oct 30
Thinking about this from a security perspective we'd need to be careful about path-traversal attacks, but otherwise Chrome is designed to view untrusted and potentially-malicious webpages (and PDFs), so as long as we don't enable any additional plugin attack surface with this feature I don't believe it should increase the attack surface. Definitely want someone from chrome OS security to confirm, as I'm not intimately familiar with the threat model details that might come up with this interaction.
,
Oct 30
Adding jorgelo@ to get his opinion.
,
Jan 3
Issue 916020 has been merged into this issue.
,
Jan 3
jorgelo@ any opinion on this? Since we have the Linux container's files mounted and accessible by Chrome OS; we can technically do this. I can manually type this into Chrome as a file URL myself and it works...albeit with a slightly ugly path like: /media/fuse/crostini_0123456789abcdef1234567890abcdef_termina_penguin/foo.txt
,
Jan 11
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by benwells@chromium.org
, Oct 30