Re: [Xsltforms-support] Can't put file to current directory

[COUTHURES A. <ala...@fr...>]

Chester,
>
> Sorry, I'm no security expert, but I don't get how anyone could crash 
> the system. When running the browser as an ordinary user, all 
> processes inherit my privileges, so if my xforms script tries to write 
> somewhere dangerous, the OS will prevent this. When I run the example 
> program under the Firefox xforms extension, it creates the file with 
> me as the owner. I would not be able to overwrite any file that I 
> don't have OS permissions to write to.
> In order to be able to do this, xlstforms would have to be running 
> setuid, and I'm quite sure that it's not.
Unfortunately, when creating Windows, Microsoft didn't want to declare a 
default ordinary user but an administrator and, today, a huge portion of 
browsers are running with maximal permissions. That's why Javascript is 
strongly restricted. I didn't test it myself but I think that using a 
Java applet allows anything so the worst too!
>
> No, I'm not sure what you're suggesting, but I don't want a file 
> dialog box at all. The dialog is appropriate for the <upload/> 
> control, but not the <submission/> element. There the file name is 
> hard-coded (or calculated).
The only secure possibility for me is to allow to inhibit the file 
dialog just when the domain is localhost or when the page is in fact 
itself loaded directly from the local disk. Would it be OK for you?
> Many examples of this exist in sample code in xforms tutorials. Here's 
> a simple example from Steven Pemberton's tutorial 
> <http://www.w3.org/MarkUp/Forms/2010/xforms11-for-html-authors/part2.html#Repeat>:
>
> <model>
> <instance src="todo-list.xml"/>
> <submission method="put" action="todo-list.xml" replace="none"/>
> <bind nodeset="todo/date" type="xsd:date"/>
> </model>
>
> In this example a do list is read from a file and written back. The OS 
> will not allow the file write unless the user running the browser has 
> privileges to do the write.
This is not a file:// example but an XRX example: the submission is sent 
to the server not to the local disk.
>
> Now what if a malicious (or ignorant) xforms designer sent me an xform 
> that tried to write to someplace bad? First, I would have to install 
> the host document somewhere (we're only talking about host documents 
> that are opened with "file://" URL's; if the document were opened with 
> "http://", then the browser would prohibit local writes as a 
> cross-domain issue).
The applet allows to save locally even if the document is opened with 
"http://" !
>
> Then, after saving the host document as a file, I would have to  log 
> in as root to run the browser or somehow allow the privileges to be 
> escalated by typing in a password. If I were stupid enough to do that 
> (and sure, it is possible!), one thing that would mitigate the damage 
> here would be if xlstforms were to only allow writes to the current 
> directory or its subdirectories, i.e., prohibit access to any path 
> with ".." in it. I noticed that the Firefox browser enforces that, in 
> fact it will not follow such a path for read references either.
Linux is surely much protective that Windows ;-)

Thanks!

-Alain