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

[Chester W. <ch...@de...>]

Alain,

Thanks very much for the reply.

On Thu, Mar 31, 2011 at 1:19 PM, COUTHURES Alain <
ala...@ag...> wrote:

>
>> I don't want to include in XSLTForms an applet that would permit anyone to
> crash a system.


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.

>
>
>> The default behavior is to propose the last file name which was used. You
>> want to change this with your own file name, is it right?
>
>
> It is already possible to enter a full name such as
> "file://test/myfile.xml" but I don't think it's a recommended notation. This
> full name will be used to initialize the file dialog box.
>
> If so, you could also need to get the chosen fullname from the latest file
> dialog box. This is not specified in the XForms Recommendation but surely
> the event() function could be used for that. Would you like me to ask the
> W3C Forms Work Group about that?
>
>
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).
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.

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

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.

So that is the only security enforcement that xlstforms needs to do IMHO.

Thanks for listening

Chester Wood


Thanks!
>
> -Alain
>
>