[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re (4): Configuring Iceweasel security policies.



From:	Scott Ferguson <prettyfly.productions@gmail.com>
Date:	Wed, 15 Jun 2011 23:12:59 +1000
> 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??

Yes, that happens when the file URI originates from the remote server.
No problem when the URI is created locally.

> Does it work with Lynx - Konqueror, Opera, Chrome, or any other web
> browser??

Dalton's address is 142.103.107.137.  In these tests, file:///Category2.xhtml 
and file://142.103.107.137/Category2.xhtml should have the same meaning.  

When these file URI are retrieved from the remote server,
elinks opens file://142.103.107.137/Category2.xhtml and file:///Category2.html, 
lynx and w3m open file:///Category2.html but not file://142.103.107.137/Category2.xhtml 
and Iceweasel, Chromium and Opera open neither.  Have yet to try Firefox and Konqueror.

> 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?

Web page editing is done at home and also at work.  A local copy would have 
to be kept at both sites.  That introduces the problem of site consistency.
The simplest solution is to keep just one copy on flash storage and carry 
it with me from one site to the other.  There is already a CF card used 
this way on the ETHNO systems.  So I would be adding a second flash store.  
Then I would have the primary copy of some files on the CF card and other 
files on the flash used in the Debian systems.  I prefer to avoid that.   
Another possibility is to jettison the ETHNO systems and 
use only a Debian system at each site.  I have trouble jettisoning a simple 
and reliable system which is really efficient for most elementary tasks.  
The file URI would be helpful if it worked.  A compromise is to first open 
the testing copy of Category2.xhtml on Dalton, using the Iceweasel or Chromium 
application menu.  As long as the window remains open, the file can be 
retested with the refresh button.  One click.

Meanwhile, I'll pursue fixing the response to the file URI.

> As you are only serving static files you might
> even be able to use rsync or sftp/fish to achieve the same thing.

ftp is good for home to shaw.ca.  By extension through the VPN tunnel, 
ftp also works from the "work" site to shaw.ca.  FTP is fast!

> 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)

At present I agree with everything there.

> 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.

At present I agree with everything there.

> > Many Web pages contain links to pages on remote servers.
> 
> Yes - that's completely different, and, it's one of the solutions I
> proposed.

No issue.

> 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.

Exactly the feature appearing not to work as it should according to Mozilla 
Security Policy.

> 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.

Yes, "each person loading the page sees their own file system".  
"the world can view" implies public access; I'm fairly sure you didn't 
mean that.

No objection to the default setting.  My complaint is that the instructions 
in Mozillazine Security Policy are not working.

> 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.

Might try Firefox and Konqueror but I expect them to behave as Iceweasel,  
Chromium and Opera do rather than as elinks.  

> The following works on my machines - no modification of browsers required:-

That is your own Category2.html file?  You get the link from my primary page 
or your's?  If the second case, where does it reside?

Thanks,              ... Peter E.


-- 
Telephone 1 360 450 2132.  bcc: peasthope at shaw.ca
Shop pages http://carnot.yi.org/ accessible as long as the old drives survive.
Personal pages http://members.shaw.ca/peasthope/ .



-- 
Telephone 1 360 450 2132.  bcc: peasthope at shaw.ca
Shop pages http://carnot.yi.org/ accessible as long as the old drives survive.
Personal pages http://members.shaw.ca/peasthope/ .


Reply to: