Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 15:22 UTC (Fri) by drag (guest, #31333)
In reply to: Guile security vulnerability w/ listening on localhost + port by NAR
Parent article: Guile security vulnerability w/ listening on localhost + port

> Than how shall I check the generated HTML documentation for my project? Or read the the documentation from /usr/share/doc?

You need to map the files or directories containing the files you want to view to the browser's file system namespace.

Mount binds is one simple way to do it.

A more advanced theoretical 'user friendly' approach would be to use something like a Fuse file system that makes up the browser's file system namespace. When the browser is launched the fuse file system is launched to go along with it.

You could then run a command like 'html-browser-open' on a particular file or directory and have that file or directory mapped to the browser's namespace. The browser could be modified slightly to monitor the 'mapping directory' and automatically open up whatever shows up there.

'html-browser-open' could be command line, or issued from the GUI file manager, or a dbus instruction. Simple access control lists could control what applications are allowed to issue these types of requests. Users could control these lists and be notified in the case of some application sending a request to another application unexpectedly.

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 15:42 UTC (Fri) by niner (subscriber, #26151) [Link] (1 responses)

Right now, half of the time I click a link in some application, the opened chromium window greets me with a failure to open my profile because it didn't notice that chromium was already running and started another one.

My faith in a working solution with added security is less than noteworthy.

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 16:46 UTC (Fri) by drag (guest, #31333) [Link]

bugs happen. You should file a report.

$ echo 'cow' > index.html
$ xdg-open index.html

works well for me.

I have found that a lot of applications try to be 'too smart' about things when trying to launch other 'helper' applications. They try to create their own solutions instead of just using the 'standardized' interfaces like the ones defined by the 'X Desktop Group'. Especially anything to do with email tends to be nightmarishly incorrect and/or cludgy since much of what gets installed pre-dates xdg stuff.

And, besides, even if your stuff is broken wouldn't it be better to have it 'broken and more secure' then 'broken and less secure'?