FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 06-16-2011, 02:29 AM
 
Default 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/ .


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 171057039.75588.30749@cantor.invalid">http://lists.debian.org/171057039.75588.30749@cantor.invalid
 
Old 06-16-2011, 09:52 AM
Scott Ferguson
 
Default Re (4): Configuring Iceweasel security policies.

On 16/06/11 12:29, peasthope@shaw.ca wrote:
> From: Scott Ferguson <prettyfly.productions@gmail.com>
> Date: Wed, 15 Jun 2011 23:12:59 +1000
<snipped>
>
>> 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_htmlxxxx.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!

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

I meant the viewer is fooled into thinking the world can see their files
- at the time there was stories that said it did. A bit like the story
that mobile phones cause explosions - if 15 million idiots believe a
stupid thing - it's still stupid. But if 5 journalist repeat it.... :-(

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

Check and correct. Otherwise people may cease to RTFM :-D

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

It's my creation (but you welcome to it!) - both Category2.html and
Category3.html reside in the same location. I did try numerous
variations in an attempt to see your perspective.

>
> Thanks, ... Peter E.
>
>


Cheers

--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DF9D24C.2030106@gmail.com">http://lists.debian.org/4DF9D24C.2030106@gmail.com
 

Thread Tools




All times are GMT. The time now is 07:04 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org