Re: Re (3): Configuring Iceweasel security policies.
On 15/06/11 13:12, peasthope@shaw.ca wrote:
> From: Scott Ferguson <prettyfly.productions@gmail.com>
> Date: Mon, 13 Jun 2011 15:30:27 +1000
>> To clarify - is it only you that needs to be able to use this file link??
>
> Yes, only me. The objective is to simplify my testing procedure.
> Of course, the time I've spent to understand it probably outweighs
> the time that will be saved.
>
>> If so - would you only be accessing it from Dalton (or where)??
>
> Yes, only from Dalton.
OK - so there's no security concerns from the link while in the page
while its on the public server. And the same page when copied locally
isn't publicly accessible....
So basically what you want is:-
A page on the public web server with an absolute file:/// link that
points to a non-existent location (relative to the web server)
The same page saved locally means the same link will then point to a
local location.... (relative to the localhost)
If I try the same thing here on this network (Class C) I can reach
machines on the same subnet - but not the filesystem. That has nothing
to do with weblinks though - just simple authentication. The same
problem doesn't occur when I use a terminal because the remote machine
sees the connection user, and authenticates the user - but a connection
from the browser, well, it's not a user.
And your problem is that Iceweasel is stopping you from loading a file
that the user running Iceweasel has permission to read and is on the
same machine??
Does it work with Lynx - Konqueror, Opera, Chrome, or any other web
browser??
Wouldn't this whole process be simpler if you just had a local copy of
the website - test there and then push the changes up to the production
server?
That's the process I use - when I'm happy with the changes I just upload
and additional or modified files, remotely connect to the mysql server
and update the database. As you are only serving static files you might
even be able to use rsync or sftp/fish to achieve the same thing.
>
>> Yes - that is as it should be. A web page should only be able to load a
>> file from within it's *purview*. So a http link should point to
>> somewhere within the root of the web server (eg. /var/www or
>> ~/public_html), and a file link should point to somewhere on the same
>> machine the link is served from (think of the authentication).
>
> Sorry to say, I have an argument. Consider the principle of user
> centrism. "http://en.wikipedia.org/wiki/User_centered_design";
> Suppose user X sits in front of the console showing the Iceweasel interface
> and sees the text "file:///"<path>. Is that file URI any different
> whether it came from a remote machine or was typed in by X or was pasted
> to the URI bar from the clipboard. No.
That is my understanding.
Consider what happens from a user point of view
User sitting at Dalton wishes to open a file on Dalton.... permissions
allowing it's possible, which implies authentication (ok?)
If the html file is on Dalton and the file link
(file:///home/peter/test.html) points to /home/peter/test.html the same
process happens - and you should be able to load that file.
Additionally if that link is http://test.html it should fail (no web server)
> In all cases it is still that
> same text residing in a buffer used by Iceweasel. Furthermore, that file
> URI always refers the local filesystem; even if the "file:///"<path>
> was retrieved from a remote system. Therefore the browser should open
> the file URI equally well, regardless of origin. If a remotely originated
> file URI, or any URI, can be blocked from opening, OK; but the blockage
> should be configurable. Not hard coded.
>
>> So a http link should point to somewhere within the root of the web server ...
Poorly put.
Let me re-phrase that - if it directly links to a file (using
http://path), that file *should* reside within the root of the
webserver. (not must). That's distinct from http://server/path
Additionally if your webserver root is /home/peter/public_html (on
shaw.ca) you could have a page (eg.index.html) with a link
http://../category1.html
Even if /home/peter/catergory1.html exists the link should fail - not
due to a restriction in Iceweasel - just sane webserver settings. That's
not to say the server can't be misconfigured.
Also as I'm sure you realise there's no way a file served on shaw.ca can
link to Dalton without you setting up portforwarding and a web server
(on Dalton) - even with insane firewall rules.
>
> Many Web pages contain links to pages on remote servers.
Yes - that's completely different, and, it's one of the solutions I
proposed.
>
>> ... a file link should point to somewhere on the same machine the link is served from ...
>
> "file:///"<path> is equivalent to "file://localhost/"<path>. This should be
> true regardless of the origin of the URI text. Where a file URI poses a
> significant threat, block it. The circumstance of viewing a file URI
> doesn't change its meaning.
Yes. I've never disputed that.
Oh course a file link (file:///) in a web page can't link outside of the
machine on which the page is viewed - unless the browser has the ability
to support the files system (eg. sftp, nfs, cifs etc) and can be
authenticated when authentication is required (most sane networking
setups require authentication).
With the following proviso:-
If the page with the file link (file:///) is being served by a *remote*
webserver - you need to turn off the restriction in the browser (as you
have already done). Understanding that file link will actually point to
a location on the viewing machine.
Back before Firefox it used to be considered amusing to put a link in a
publicly accessible web page like file:///C:/autoexec.bat and tell the
visitor the world can view their file system (each person loading the
page sees their own file system). That is what the default setting in
Iceweasel prevents.
> As I undertand http://kb.mozillazine.org/Security_Policies , Iceweasel with the correct
> settings in /etc/iceweasel/pref/iceweasel.js should open the file URI as I
> describe. Does Iceweasel have a problem not existing in Mozilla? A Mozilla
> forum or mailing list might help. Also I can file a bug report against Iceweasel
> and see what the maintainers say.
That would be "maintainer" singular (Mike Hommey) - the man whose wish
list is "more developer, more developers, and more developers".
Before doing that - perhaps you could try with Firefox, Konqueror,
Chrome, Lynx before you ask for a fix - just in case it's not brokenam.
:-)
The following works on my machines - no modification of browsers required:-
<html>
<head>
<title>Category2</title>
</head>
<body>
<p><a href="file:///home/scott/Category3.html">file</a></p>
</body>
</html>
>
> Thanks for the extensive discussion,
>
> ... Peter E.
>
And thank you for the semantic and mental exercise!
Cheers
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
Reply to: