Configuring Iceweasel security policies.
After reading http://kb.mozillazine.org/Security_Policies
add these four lines to dalton:/etc/iceweasel/pref/iceweasel.js .
// Allow my file URI to be opened.
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.localfilelinks.sites",
"http://pe...@members.shaw.ca:80";);
# From: Scott Ferguson
# Date: Fri, 10 Jun 2011 17:31:08 +1000
> Soft links'll work fine.
OK, dalton:/Category2.html is now a soft link to /home/peter/Category2.html.
At dalton open
http://members.shaw.ca/peasthope/#Links
and click on the link file:///Category2.html .
This message comes to the Iceweasel error console.
Security Error: Content at http://members.shaw.ca/peasthope/#Links may not load
or link to file:///Category2.html.
Appears that the instructions for the Mozilla security policies are for the
case
where both the file URI link comes from the same machine as the browser runs on.
Any better ideas to configure for my case where the file URI link is in
members.shaw.ca/peasthope and the browser is on dalton?
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/ .
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/171057034.50720.43927@cantor.invalid
Re: Configuring Iceweasel security policies.
From: peasth...@shaw.ca Date: Fri, 10 Jun 2011 12:24:32 -0800 > Appears that the instructions for the Mozilla security policies are for the > case > where both the file URI link comes from the same machine as the browser runs > on. That was garbled. This might make more sense. Are the instructions for the Mozilla security policies for the case where the page containing the file URI link and the page targeted are on the same machine? Any better ideas to configure for my case where the file URI link is in members.shaw.ca/peasthope and the target page and browser are on dalton? 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/ . -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/171057034.51641.43928@cantor.invalid
Re: Configuring Iceweasel security policies.
On Fri, 10 Jun 2011 12:24:32 -0800, peasthope wrote:
> After reading http://kb.mozillazine.org/Security_Policies add these four
> lines to dalton:/etc/iceweasel/pref/iceweasel.js .
(...)
> This message comes to the Iceweasel error console. Security Error:
> Content at http://members.shaw.ca/peasthope/#Links may not load or link
> to file:///Category2.html.
(...)
Check if this helps:
***
http://www-archive.mozilla.org/releases/mozilla1.7.12/known-issues.html#psm
For security reasons, Mozilla does not allow web content to link to local
files. An error like:Security Error: Content at url may not load or link
to file:///something will appear in the javascript console. If you need
to follow links to local paths it is recommended that you drag the link
to the location bar and then drop it on the webpage. If you really don't
like the security check and are willing to risk all files on your system
and that your system can access then you may add the following line to
user.js in your personal profile directory. user_pref
("security.checkloaduri", false); (Bug 84128)
***
I mean, the part where it says how to disable the security check (I hope
you really know what you are doing here...).
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pan.2011.06.11.11.11...@gmail.com
Re: Configuring Iceweasel security policies.
On 11/06/11 06:24, peasth...@shaw.ca wrote:
> After reading http://kb.mozillazine.org/Security_Policies
> add these four lines to dalton:/etc/iceweasel/pref/iceweasel.js .
>
> // Allow my file URI to be opened.
> user_pref("capability.policy.policynames", "localfilelinks");
> user_pref("capability.policy.localfilelinks.checkloaduri.enabled",
> "allAccess");
> user_pref("capability.policy.localfilelinks.sites",
> "http://pe...@members.shaw.ca:80";);
Now that's confusing me too! I've never had to modify anything to get a
web browser to load local files or to load links from local files
either to local links or online links.
>
> # From: Scott Ferguson
> # Date: Fri, 10 Jun 2011 17:31:08 +1000
>> Soft links'll work fine.
>
> OK, dalton:/Category2.html is now a soft link to /home/peter/Category2.html.
>
> At dalton open
> http://members.shaw.ca/peasthope/#Links
> and click on the link file:///Category2.html .
I don't think that will work - for it to work *I* would have to have a
file called Category2.html in my / directory
(mea culpa) As usual I've explained myself poorly.
Judging from the apache modules:-
members.shaw.ca gives you an account for peasthope - in your home
directory is a directory called public_html which is the root of webserver.
eg. /home/peasthope/public_html
You are probably free to create other directories beneath your home
eg. /home/peasthope/stuff
You have something you'd like to link to from webpage - the webpage
lives somewhere in public_html.
eg. /home/peasthope/public_html/index.html
Normally I would only serve files that live beneath public_html, and I
would/do use additional directories to make content management easier
(with static sites), using .htaccess files in each directory to control
what can be accessed.
Occasionally I might put some files in /home/peasthope/stuff and
soft-link them into public_html, just temporarily for testing purposes.
In your case you might be able to use that technique. You should then be
able to use LDAP to access the files in /home/peasthope/stuff - as long
as you don't change the name of the files, the soft-links will continue
to work as you change files.
Probably best if I reread your posts tomorrow when I'm less distracted -
I'm not sure I fully understand what you require.
>
> This message comes to the Iceweasel error console.
> Security Error: Content at http://members.shaw.ca/peasthope/#Links may not
> load or link to file:///Category2.html.
>
> Appears that the instructions for the Mozilla security policies are for the
> case
> where both the file URI link comes from the same machine as the browser runs
> on.
>
> Any better ideas to configure for my case where the file URI link is in
> members.shaw.ca/peasthope and the browser is on dalton?
You can't. That I know of. The link cannot be relative. I can't think of
how to use an absolute link across your network (firewall, network
protocols etc).
Need. more. coffee. will read the referenced mozillazine...
>
> Thanks,... Peter E.
>
Cheers
--
Tuttle? His name's Buttle.
There must be some mistake.
Mistake? [Chuckles]
We don't make mistakes.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4df36c52.1050...@gmail.com
Re: Configuring Iceweasel security policies.
On 11/06/11 06:38, peasth...@shaw.ca wrote: > From: peasth...@shaw.ca > Date: Fri, 10 Jun 2011 12:24:32 -0800 >> Appears that the instructions for the Mozilla security policies are for the >> case >> where both the file URI link comes from the same machine as the browser runs >> on. > > That was garbled. This might make more sense. > > Are the instructions for the Mozilla security policies for the case where the > page containing the file URI link and the page targeted are on the same > machine? > > Any better ideas to configure for my case where the file URI link is in > members.shaw.ca/peasthope and the target page and browser are on dalton? > > Thanks,... Peter E. > > I'll have a think about that and try and get back to you tomorrow night. http://pe...@members.shaw.ca/ (from your policy in the last post) A login on a site with no authentication?? Cheers -- Tuttle? His name's Buttle. There must be some mistake. Mistake? [Chuckles] We don't make mistakes. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df3865c.3090...@gmail.com
Re: Configuring Iceweasel security policies.
On 12/06/11 12:05, peasth...@shaw.ca wrote: > * From: Scott Ferguson > * Date: Sat, 11 Jun 2011 23:23:30 +1000 > Here is my explanation again, step by step. > * I sit in front of the console of dalton. > * Using Iceweasel in Squeeze, open this. > "http://members.shaw.ca/peasthope/#Links"; > It's public. Have a look. > * There I see the link with anchor file:///Category2.html and target the same. > * Click on that anchor. I expect dalton:/home/peter/Category2.html > open but nothing happens except for the message to the Iceweasel > error console. Ref. earlier message. Is there a syntax such as > dalton.invalid:file:///Category2.html ? Yes. > * Save the page "http://members.shaw.ca/peasthope/"; onto storage of Dalton. > * Open that page on Dalton. > * Now in this image from the local copy, click on the anchor > file:///Category2.html. > * Now Category2.html opens. > > > The steps above demonstrate that the link from dalton:/Category2.html > to dalton:/home/peter/Category2.html works. Stepping through what you've described above... You are on a Dalton console. If you are *not* running as root (and why would you be?) ~$ pwd ~$ /home/peter You saved the page to "storage of Dalton" presumably "storage" is somewhere below /home/peter eg.:- home/peter/"Peter Lyall Easthope.html" That page contains a link:- [a href="file:///Category2.html"]file:///Category2.html[/a>] That link points to Category2.html ie.:- ~$ mlocate Category2.html (would give based on the info given...) ~$ /home/peter/Category2.html You then say that the link works (I don't disbelieve you)- but that link is pointing at the root of Dalton, not the root of Peters home directory So "something" I'm assuming in the above scenario is not correct. Just to clarify:- When you click on a http link in a html page the link is "relative" to the web server. If the server is a webserver (eg. Apache) the root is (generally) /var/www. The module running on the apache server at member.shaw.ca means a virtual server for each user has it's root in the users home directory eg. /home/peter (unlikely as you have config files there) OR /home/peter/public_html (more likely as now only files used by the web server are in the root of the web server). You shouldn't be able to save "Peter Lyall Easthope.html" to anywhere above your home directory - and yet the file link in it will always point to the root of Dalton. This is because an absolute file link in a local (same machine) .html file always has the base of it's path as the / of that local machine (where localhost is). ie doesn't matter whether "Peter Lyall Easthope.html" lives at:- /"Peter Lyall Easthope.html" /etc/"Peter Lyall Easthope.html" /var/log/apt/"Peter Lyall Easthope.html" OR even /home/peter/"Peter Lyall Easthope.html" The link file:///Category2.html will always point to /"Peter Lyall Easthope.html" Because the browser replaces "file" with localhost, which renders the URI /"Peter Lyall Easthope.html" (damn absolute links!) I'm sure, somewhere in all these threads you've explained what Dalton is running, but I'm a little confused with talk of Oberon and vnc connections to Iceweasel running on other machines. When I refer to localhost I mean the machine that hosts Iceweasel. I'm also assuming that Iceweasel is not running as root, and that the directory that you save "Peter Lyall Easthope.html" into is mounted on the same machine as the file Category2.html. Please correct my misunderstanding. > >> http://pe...@members.shaw.ca/ (from your policy in the last post) >> A login on a site with no authentication?? > > Authentication is not necessary to look at a public Web page. Agreed - *but* http://pe...@members.shaw.ca/ is asking the browser to login to members.shaw.ca. And the server on shaw.ca says "I'm sorry Dave but" :-D So what the browser is actually served is members.shaw.ca eg.:- http://pe...@members.shaw.ca/ == http://members.shaw.ca/ Which seems like a waste of 6 characters ;-p > > Regards,... Peter E. > > Cheers, and thanks for your patience. -- It's just a ride and we can change it any time we want. It's only a choice. No effort, no work, no job, no savings and money, a choice, right now, between fear and love. The eyes of fear want you to put bigger locks on your door, buy guns, close yourself off. The eyes of love instead see all of us as one. ~ Bill Hicks -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df492e1.5090...@gmail.com
Re(2): Configuring Iceweasel security policies.
* From: Scott Ferguson * Date: Sat, 11 Jun 2011 23:23:30 +1000 > Now that's confusing me too! I've never had to modify anything to get a > web browser to load local files or to load links from local files > either to local links or online links. Again, we're at crossed purposes. The problem isn't local. Here is my explanation again, step by step. * I sit in front of the console of dalton. * Using Iceweasel in Squeeze, open this. "http://members.shaw.ca/peasthope/#Links"; It's public. Have a look. * There I see the link with anchor file:///Category2.html and target the same. * Click on that anchor. I expect dalton:/home/peter/Category2.html open but nothing happens except for the message to the Iceweasel error console. Ref. earlier message. Is there a syntax such as dalton.invalid:file:///Category2.html ? * Save the page "http://members.shaw.ca/peasthope/"; onto storage of Dalton. * Open that page on Dalton. * Now in this image from the local copy, click on the anchor file:///Category2.html. * Now Category2.html opens. > ... for it to work *I* would have to have a > file called Category2.html in my / directory The steps above demonstrate that the link from dalton:/Category2.html to dalton:/home/peter/Category2.html works. > members.shaw.ca gives you an account for peasthope - in your home > directory is a directory called public_html which is the root of webserver. > eg. /home/peasthope/public_html > You are probably free to create other directories beneath your home > eg. /home/peasthope/stuff A reasonable hypothesis. Normally files are put there with "ftp://peasth...@ftp.shaw.ca/";. Only files are there. No sub-directory. But I don't see the relevance. > > Any better ideas to configure for my case where the file URI link is in > > members.shaw.ca/peasthope and the browser is on dalton? > > You can't. That I know of. The link cannot be relative. I can't think of > how to use an absolute link across your network (firewall, network protocols > etc). As mentioned a few days back, the third of those file URIs "file:Category2.html" works for ETHNO. Is this only a quirk of the ETHNO interface? Doesn't make sense that Iceweasel doesn't know what to do when a link targeting file:///Category2.html is clicked. What could be simpler? Should be only a security issue. The source code will explain of course. If it can be comprehended. Ugg. * From: Scott Ferguson * Date: Sun, 12 Jun 2011 01:14:36 +1000 > http://pe...@members.shaw.ca/ (from your policy in the last post) > A login on a site with no authentication?? Authentication is not necessary to look at a public Web page. Regards,... 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/ . -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/171057035.74067.62627@heaviside.invalid
Re (2): Configuring Iceweasel security policies.
From: Scott Ferguson Date: Sun, 12 Jun 2011 20:20:17 +1000 > Stepping through what you've described above... > > You are on a Dalton console. By console I mean the SVGA monitor, keyboard and mouse. It supports X11 in addition to plain CLI. > If you are *not* running as root (and why would you be?) Correct. User peter. > You saved the page to "storage of Dalton" presumably "storage" is > somewhere below /home/peter > > eg.:- > home/peter/"Peter Lyall Easthope.html" Here I stored it as /home/peter/Desktop/index.html. The choice of name doesn't change the phenomenon being demonstrated. We're dealing with two pages. There is the "primary" page containing the Web link. Then there is the page Category2.html which is target of the link in the primary page. Category2.html is always local. I can open Category2.html when the primary page is local. Not when the primary page is remote. > You then say that the link works (I don't disbelieve you)- but that link > is pointing at the root of Dalton, not the root of Peters home directory > So "something" I'm assuming in the above scenario is not correct. Yes. There is a filesystem soft link as we discussed a day or two back. peter@joule:~$ sudo ln -s /home/peter/Category2.html /Category2.html peter@joule:~$ ls -l /C* lrwxrwxrwx 1 root root 23 Jun 12 13:16 /Category2.html -> /home/peter/Category2.html The filesystem and the Web both having "links" is a possible source of confusion. > Just to clarify:- > When you click on a http link in a html page the link is "relative" to > the web server. > ... > Because the browser replaces "file" with localhost, which renders the > URI /"Peter Lyall Easthope.html" (damn absolute links!) Yes, we're in sync for everything in those 5 paragraphs. Keep in mind the filesystem link from ln -s above. That lets me open /home/peter/Category2.html by targeting file:///Category2.html. > I'm sure, somewhere in all these threads you've explained what Dalton is > running, Dalton runs Squeeze and Iceweasel. > but I'm a little confused with talk of Oberon and vnc > connections to Iceweasel running on other machines. VNC is completely irrelevant to this discussion. It was only part of an answer to Ron J. Oberon was mentioned only to illustrate how I expected a rational browser to behave. Oberon is not necessary to demonstrate the behaviour of Iceweasel. > When I refer to > localhost I mean the machine that hosts Iceweasel. Yes, dalton. > I'm also assuming > that Iceweasel is not running as root, Correct. > ,,, and that the directory that you > save "Peter Lyall Easthope.html" into is mounted on the same machine as > the file Category2.html. Yes. That is dalton. > Agreed - *but* http://pe...@members.shaw.ca/ is asking the browser to > login to members.shaw.ca. > And the server on shaw.ca says "I'm sorry Dave but" :-D > So what the browser is actually served is members.shaw.ca > eg.:- > http://pe...@members.shaw.ca/ == http://members.shaw.ca/ > > Which seems like a waste of 6 characters ;-p Correct. I put in the "peter@" when trying to imagine the meaning of the error message from Iceweasel. I'll remove it. The final observation is that there should be a way to open file:///blah.html, regardless of where the link resides. At present I can open it only with a link in a local page. The link on a remote server, targetting file:///blah.html, produces only the error message from Iceweasel. file:/// is always an absolute file name on the local machine isn't it? Is there a syntax for a non-local file:///? Logically, that should not be necessary, but it might help with troubleshooting. Hopefully the failure of the non-local case is just a security default which can be overridden. Otherwise it's a bug in Iceweasel. > Cheers, and thanks for your patience. Thanks for your patience. The thread is becoming stale and there are too many small digressions. A fresh description of the problem with new names might help ... except that everyone must be fed up with it by now. Regards, ... 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/ . -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/171057036.62341.52315@heaviside.invalid
Re (3): Configuring Iceweasel security policies.
From: Scott Ferguson 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. > 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:///". 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. 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:///" 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 ... Many Web pages contain links to pages on remote servers. > ... a file link should point to somewhere on the same machine the link is > served from ... "file:///" is equivalent to "file://localhost/". 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. 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. Thanks for the extensive discussion, ... 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/ . -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/171057038.78606.51225@cantor.invalid
Re (4): Configuring Iceweasel security policies.
From: Scott Ferguson 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
Re (5): Configuring Iceweasel security policies.
From: Scott Ferguson
Date: Thu, 16 Jun 2011 19:52:12 +1000
> ... lynx doesn't support xhtml by default ... w3m only support xhtml 1.0
>
> Try not using an xhtml file - I suspect you are complicating your tests.
Oops; thanks. The result is the same for C*.html. When lynx and
w3m are given the IP address, they decline to open the file. But
these file links are edge cases; odd behaviour is no surprise.
> I'm not understanding why you are using the ip address - even localhost
> is redundant... with file:/// links localhost is the default root
Only wondered what the browsers would do when the target is specified
explicitly. Just my inane curiosity.
> Hmm - do you mean that you are using a local copy ... ?
Definitely. If the target is on the Web server, there is no problem
and no reason to test. The problematic case is for the file URI.
> You *did* change the restrictions in Iceweasel (about:config) didn't you?
That's where I started about 5 days ago. In about:config,
security.checkloaduri
appears to be changeable but the change doesn't stick and has no effect.
According to the mailing lists, that appears to be intentional. So then
I tried editing /etc/iceweasel/pref/iceweasel.js as "docuemented" in
Mozilla Security Policy. Even when the configuration is set,
about:config security.checkloaduri is true. Either my configuration
is wrong or Iceweasel doesn't implement this as Mozillazine describes.
This is the pertinent content of iceweasel.js.
// Allow my file URI to be opened.
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.localfilelinks.sites", "http://members.shaw.ca/";
"file://142.103.107.137/" );
In chromium-browser, about:config doesn't work. There are files in
/etc/chromium-browser
but I haven't had time to chase down the configuration perinent to file URI.
Similarly for
the other optional browsers.
> I generally test changes on a server in a virtualbox machine before
> pushing them to the development server (belt and suspenders).
OK, I understand that for testing. Where do you edit the pages?
Which editor?
> For a static site such as yours I suggest you just tar.bzip ...
That would be another procedure in my system of work. Make it
as simple as possible but not simpler.
> A later dated archive always replaces an earlier dated archive. And a
> changes text file can be used to keep track of versions.
I have daily, weekly and monthly backups. Even when the
filesystem on the CF card failed, all data including current
bookkeeping, was recovered in about an hour. Versioning is not
needed for my trivial Web sites.
>> FTP is fast!
>
> Even faster when it's only moving a tar.bz2!
I understand but in many cases I just update one file after an
edit. Updating the dozen or so files comprising a Web site is
still only three mouse clicks in about 5 seconds.
> You may have found a difference between Firefox and Iceweasel
I must install FF to resolve it.
> I meant the viewer is fooled into thinking the world can see their files
> - at the time there was stories that said it did.
OK, I missed that.
> ... both Category2.html and Category3.html reside in the same location.
Works for me too. No issue. Put your Category2.html on a Web
server and your Category3.html on your workstation. Open Category2.html
in a browser on your workstation. Click on the file link targetting
Category3.html, which is on your workstation. I'll bet Category3.html
will not open. If you can find a configuration setting to allow that
to work, good!
Regards, ... 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/ .
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/171057040.43841.30760@cantor.invalid
Re (6): Configuring Iceweasel security policies.
From: Camaleon Date: Thu, 16 Jun 2011 18:25:47 + (UTC) > Err... Peter, have you considered using the suggestedA1 extension? > https://addons.mozilla.org/firefox/addon/281 I had foolishly assumed it wouldn't work for Iceweasel; but it does, in Iceweasel 3.5.16 in Squeeze. Thanks! > ... consider opening a bug at Firefox bugzilla for the things that you > have already tried and did not work ... That had crossed my mind. After all, an add-on to cancel the security add-on might not be the most elegant way to open a file. OK, I'm stretching it but you get my drift. Thanks again, ... 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/ . -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/171057040.63847.30761@cantor.invalid
Re: Re (2): Configuring Iceweasel security policies.
On 13/06/11 09:14, peasth...@shaw.ca wrote: > From: Scott Ferguson > Date: Sun, 12 Jun 2011 20:20:17 +1000 >> Stepping through what you've described above... >> >> You saved the page to "storage of Dalton" presumably "storage" is >> somewhere below /home/peter >> >> eg.:- >> home/peter/"Peter Lyall Easthope.html" > > Here I stored it as /home/peter/Desktop/index.html. The choice of name > doesn't change the phenomenon being demonstrated. Exactly! :-) > > We're dealing with two pages. There is the "primary" page containing > the Web link. Then there is the page Category2.html which is target of > the link in the primary page. Category2.html is always local. I can > open Category2.html when the primary page is local. Not when the primary > page is remote. Yes! That is how I understand this to work. > >> You then say that the link works (I don't disbelieve you)- but that link >> is pointing at the root of Dalton, not the root of Peters home directory >> So "something" I'm assuming in the above scenario is not correct. > > Yes. There is a filesystem soft link as we discussed a day or two back. Ah - thank you for the clarification. [blinking] It's all coming back to me now > peter@joule:~$ sudo ln -s /home/peter/Category2.html /Category2.html > peter@joule:~$ ls -l /C* > lrwxrwxrwx 1 root root 23 Jun 12 13:16 /Category2.html -> > /home/peter/Category2.html > The filesystem and the Web both having "links" is a possible source of > confusion. Partially. I bring my own confusion. I don't like to turn up empty handed ;-p > The final observation is that there should be a way to open > file:///blah.html, regardless of where the link resides. In a perfect world ;-p (see my final comments) > At present > I can open it only with a link in a local page. The link on a remote > server, targetting file:///blah.html, produces only the error message > from Iceweasel. 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). > file:/// is always an absolute file name on the > local machine Where "local machine" means the machine the page holding the link is loaded on (where Iceweasel is running). > isn't it? Is there a syntax for a non-local file:///? Not unless you can load a network protocol with a page link. I am unable to categorically say that is not possible - *perhaps someone knowledgeable could advise* (it may be trivial). > Logically, that should not be necessary, but it might help with > troubleshooting. > > Hopefully the failure of the non-local case is just a security default > which can be overridden. Otherwise it's a bug in Iceweasel. With my limited understanding of the network security issues - I doubt it's a bug. > >> Cheers, and thanks for your patience. > > Thanks for your patience. The thread is becoming stale and > there are too many small digressions. A fresh description of the > problem with new names might help ... except that everyone must be > fed up with it by now. > > Regards, ... Peter E. > > > To clarify - is it only you that needs to be able to use this file link?? If so - would you only be accessing it from Dalton (or where)?? There are other ways (java, a local monkey server, etc) that might be used to solve this problem. Cheers -- We all pay for life with death, so everything in between should be free. ~ Bill Hicks -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df5a073.9000...@gmail.com
Re: Re (3): Configuring Iceweasel security policies.
On 15/06/11 13:12, peasth...@shaw.ca wrote: > From: Scott Ferguson > 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:///". 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:///" > 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:///" is equivalent to "file://localhost/". 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
Re: Re (4): Configuring Iceweasel security policies.
On 16/06/11 12:29, peasth...@shaw.ca wrote: > From: Scott Ferguson > Date: Wed, 15 Jun 2011 23:12:59 +1000 > >> 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 My understanding is that lynx doesn't support xhtml by default - it can though:- http://www.kolpackov.net/projects/lynx/xhtml.xhtml w3m only support xhtml 1.0 Try not using an xhtml file - I suspect you are complicating your tests. I'm not understanding why you are using the ip address - even localhost is redundant... with file:/// links localhost is the default root > and Iceweasel, Chromium and Opera open neither. Have yet to try Firefox and > Konqueror. Hmm - do you mean that you are using a local copy or the page served by shaw.ca?? If it's the latter, then they (sic) are displaying safe behaviour. You *did* change the restrictions in Iceweasel (about:config) didn't you? (sorry if you've previously clarified that - I haven't had time this evening to reread all the previous threads/posts.) > >> 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. It's a very common scenario. I'd hesitate to describe it as a problem. More a feature of sane, standard, site development. The usual procedure is to test on a non-public development server - only migrating the changes to the productions server when proven. I generally test changes on a server in a virtualbox machine before pushing them to the development server (belt and suspenders). For a static site such as yours I suggest you just tar.bzip /home/peter/public_html (on shaw.ca). Call it public_html.tar.bz2 where xxx is the date and time. Change control can be as simple as creating a file without contents using the date and time as a name before archiving. eg.:- $ touch `date | sed 's/ //g'` A later dated archive always replaces an earlier dated archive. And a changes text file can be used to keep track of versions. On my development and vb machines I just use mc for creating archives (they are headless and accessed with ssh). eg. from inside public_html select the menu (F2) in mc and choose "Compress the current subdirectory tar.bz2" you'll be prompted for a filename - the default will be "public_html" - just change it include the date and time. You'll wind up with /home/peter/public_html_instance.tar.bz2 > 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. Good idea (avoiding that) - it robs you of a history of changes, and it's to easy to fail to include files, include files not needed. > 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. If it ain't broken > 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. Yes. You'll still retain the last but one change (~) > > 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! Even faster when it's only moving a tar.bz2! > >> 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. You may have found a difference between Firefox and Iceweasel > >> Back before Firefox it used to be considered amusing to put a link in a >> publicly accessible web page like
Re: Re (5): Configuring Iceweasel security policies.
On Thu, 16 Jun 2011 10:45:01 -0800, peasthope wrote:
> From: Scott Ferguson Date: Thu, 16
Jun
> 2011 19:52:12 +1000
(...)
>> You *did* change the restrictions in Iceweasel (about:config) didn't
>> you?
>
> That's where I started about 5 days ago. In about:config,
> security.checkloaduri appears to be changeable but the change doesn't
> stick and has no effect. According to the mailing lists, that appears to
> be intentional. So then I tried editing
> /etc/iceweasel/pref/iceweasel.js as "docuemented" in Mozilla Security
> Policy. Even when the configuration is set, about:config
> security.checkloaduri is true. Either my configuration is wrong or
> Iceweasel doesn't implement this as Mozillazine describes. This is the
> pertinent content of iceweasel.js. // Allow my file URI to be opened.
> user_pref("capability.policy.policynames", "localfilelinks");
> user_pref("capability.policy.localfilelinks.checkloaduri.enabled",
> "allAccess"); user_pref("capability.policy.localfilelinks.sites",
> "http://members.shaw.ca/"; "file://142.103.107.137/" );
Err... Peter, have you considered using the suggested¹ extension?
https://addons.mozilla.org/firefox/addon/281
I have tested and it works with the sample links of your site (at least
within Firefox 5.0 beta). Well, it says "file not found", of course, but
it opens the link, the error is because the file cannot be found in my
system.
It is very easy to use: once installed, you have to right-click on the
desired link ("file:///home/user/file") to open the context menu and then
open the uri in a new tab or new window. And the URI will open.
Then, consider opening a bug at Firefox bugzilla for the things that you
have already tried and did not work "as expected" :-)
¹http://kb.mozillazine.org/Links_to_local_pages_don%27t_work#Disabling_the_Security_Check
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pan.2011.06.16.18.25...@gmail.com
Re: Re (5): Configuring Iceweasel security policies.
On 17/06/11 04:45, peasth...@shaw.ca wrote: > From: Scott Ferguson > Date: Thu, 16 Jun 2011 19:52:12 +1000 > > In chromium-browser, about:config doesn't work. Does it need to? On my computer with Chrome open Ctrl+O to open the file open dialog choose /home/scott/Category2.html (has various links types in it) file opens no problems link to /home/scott/Category3.html opens no problems additionally, and just to return the confusion ;-p opens fish://machine_on_same_subnet opens sftp://machine_on_same_subnet On your webserver Chrome will open two http links on the second line of Links, none of the links on the third line of links (expected behaviour) However, if you still desire that functionality(?) try :- https://chrome.google.com/webstore/detail/jllpkdkcdjndhggodimiphkghogcpida OR simply copy and paste the local link eg. file://home/scott/Category2.html (note the double slash, not triple) >> I generally test changes on a server in a virtualbox machine before >> pushing them to the development server (belt and suspenders). > > OK, I understand that for testing. Where do you edit the pages? in situ (on the development machine, separate users and virtual hosts for each site) > Which editor? For static html pages and css - nano, vi, emac, kwrite, kate, any and all are good. I generally use a CMS so there are no actual pages. I don't use an IDE to manage sites though I use one to develop and test elements of a site eg, php, javascript, css and complex pages. I can recommend Komposer, until recently I used Quanta - but it's broken in Squeeze, I've heard good things of Bluefish, and I'm currently testing various solutions for HTML5. Kimagemap is excellent, but slightly broken, for imagemapping. Klinkchecker is invaluable (used to analyse the links on your site). wget and curl are also invaluable. > >> For a static site such as yours I suggest you just tar.bzip ... > > That would be another procedure in my system of work. Make it > as simple as possible but not simpler. > >> A later dated archive always replaces an earlier dated archive. And a >> changes text file can be used to keep track of versions. > > I have daily, weekly and monthly backups. Even when the > filesystem on the CF card failed, all data including current > bookkeeping, was recovered in about an hour. Versioning is not > needed for my trivial Web sites. > >>> FTP is fast! >> >> Even faster when it's only moving a tar.bz2! > > I understand but in many cases I just update one file after an > edit. Updating the dozen or so files comprising a Web site is > still only three mouse clicks in about 5 seconds. I lack you, um, confident optimism. That approache leaves too many states between the old and the new. I prefer:- old site old site plus new_site_archived.tar.bz2 site down to all visitors except my ip delete old site extract new site site up > Regards, ... Peter E. > > > Consider that - if something works you'll use it, the longer it's useful, the more you'll forget so overwriting leads to problems. eg. if you install knoppix fail to update knoppix install debian update debian no matter which release you're running it's Debian Cruft! ;-p don't let your site become Easthope cruft ;-p Cheers -- I don't mean to sound bitter, cold, or cruel, but I am, so that's how it comes out. ~ Bill Hicks -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dfb0430.6060...@gmail.com
