[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE Scripting Interface [2nd Try]
From:       Martin Konold <konold () kde ! org>
Date:       2001-07-20 19:04:47
[Download RAW message or body]

On Friday 20 July 2001 05:18 pm, Roberto Alsina wrote:

Hi Roberto,

> > Hmm... but what about KOffice macros when those work and get distributed
> > because people start exchanging their docs? I think we should really
> > think about that now.
>
> Don't embed the macros in the docs.

A lot of typical macro usage makes only sense for a single special document. 
Thefor putting it into our xml archive aka koffice document makes a lot of 
sense. Putting it technically into an extra file within the archive makes 
definetly a lot of sense.

> Or warn when loading a document with macros.

Sorry but this is completly useless. How should the recipient of a document 
decide if he/she should trust the macro? Maybe the macros are needed in order 
to make use of the document. 99% will click yes and 1% will bother the help 
desk which also does not know what to answer to the question:

"This document contains macros. Shall I execute them? <yes>/<no>"

IMHO the only useful thing is providing a sandbox by simply NOT offering any 
dangerious functionality to macros. The basic principles are the same like 
with offering js to html documents.

> But if you forbid macros from accessing DCOP, you have to export the
> KOffice functionality twice, and that not neat.

This is the only thing which makes sense. DCOP shall have maximum power. DCOP 
is accessed with the full priviledges of the user.

> > People who download and execute malicious executable content can and will
> > do that anyway. It is completely  pointless to have _any_ security there.

Exactly!

> > The same is not true for scripts that can _only_ be executed from the GUI
> > through an integrated scripting engine.
>
> What is the difference? Just consider kword docs as a very fancy
> executable format.

No this is a big difference. A typical user can get its job done without ever 
installing any executable but very often needs to exchange documents with 
strangers.

Consider KOffice documents as fancy executables is a VERY dangerious view.
We should consider them documents which as a maximum are allowed to destroy 
themself but which are by all means denied access to anything else incl. the 
running application and the filesystem. This includes the fact that macro may 
NOT modify another document which belongs to the same instance of the office 
application and after closing a document ALL traces of macros must be gone in 
order to prevent a worm.

> > And people _will_ start using macros in
> > documents to get tasks done, and people _will_ complain if the macro
> > engine is too restricted in a trusted environment.

Please tell me a real world case where access to filesystem is necessary from 
a macro? Allowing network access can be useful though but fortunately network 
ressources use extra credentials when necessary anyway.

> >at least get a warning if a document
> > wants to do something dangerous. If they screw up even then, then at
> > least we can't be blamed...

Sorry but see above. Warnings are useless.

Yours, 
-- martin

[prev in list] [next in list] [prev in thread] [next in thread]