Re: Of customisability, overridability and FLOSS/LibreOffice's mission

On 13/06/14 11:08, Lionel Elie Mamane wrote:
> On Fri, Jun 13, 2014 at 09:44:42AM +0100, Noel Power wrote:
> > On 12/06/14 16:16, Lionel Elie Mamane wrote:
> > > On Fri, Jun 06, 2014 at 09:55:05AM +0100, Noel Power wrote:
> > > > On 28/05/14 12:11, Lionel Elie Mamane wrote:
> > > > Security, I mentioned it in a previous mail, what you are suggesting is
> > > > basically allowing the user to rootkit the libreoffice api.
> > > I'm surprised you consider LibreOffice a security barrier /
> > > enforcer. I don't. As I see it, factually, it is an application that
> > > runs with the user's identity and privileges, that is under the
> > > control of the user and of anybody that subverts the user's
> > > environment. (...)
> > (...) It's clear you are comfortable with the idea that a user
> > extension can override the core, a hypothetical example being say of
> > a user installing a user extension that overrides the allows a user
> > XProtectable so they can easily unlock any spreadsheet to unhide
> > their bosses salary.
> (This is an interesting point, but is besides the access2base
>  discussion. I'm forking it into a separate subthread.)
>
> That's actually a good example, and similar to what I do with my PDF
> readers to allow me to copy (for paste for quotation) / print /
> ... (that is, ignore the permissions bits).
actually it is not a good example, it is, as I said a 'silly example'
> In your example, the boss's salary is available with the combination
> of "unzip / xmlindent / less" anyway,
[...]
oh please, give me a break, I simply wanted to illustrate how trivially
the application's internal consistency with regard to the api has been
broken by allowing 'users' to 'replace' api with an extension. How you
might otherwise achieve the same result (bypassing of the password in
this particular example) is completely and utterly irrelevant
[...]
>  
> Now that I think of it, LibreOffice has an indirection level that
> "service names" are mapped to "implementation names" by way of
> *configuration* files, the ".component" files. So I wouldn't be too
> surprised that by mapping a service name that is usually provided by
> core to an implementation in an extension, the kind of things you
> describe is *already* *possible*. Any LibreOffice code (even from
> core) instantiating the service would get the implementation from the
> extension (independent on the particular example, whether XProtectable
> is implemented in a service or not...). Never tested it, though.
I would be exceedingly surprised that this is the case, it would mean 1
of 2 things
a) a bug
b) or that by design a user is able to replace binary core functionality

if a) then that is a hole that would need to be *immediately* fixed imho
if b) then I would respectfully disagree with that behaviour but I would
also recognise for reasons of consistency that my whole problem with
your patch allowing "even in a limited way" for a user to override core
behaviour with an extension is baseless. However... I sincerely doubt
that is the case, I would love to hear some definitive expert opinion on
that say from Stephan, is that true then?, a user should be able to
replace internal component services (e.g. document loading, password
api, anything...) with a user extension.
> > But... the issue here isn't the silly example it's the fact that
> > libreoffice itself uses the api, it expects the code it calls via
> > the api to be the code it shipped with and to behave exactly how it
> > expects, this is one of the boundaries (or at least how I read it)
> > that Michael mentioned previously and one of the invariants the core
> > expects.
> Taking the role of the user, *this* *is* *my* *computer* and my
> installation of LibreOffice. Let me screw it up if I want. I see us
> (LibreOffice project, Free Software movement in general) as being
> about empowering the *user*.
<shrug> if this is your computer then you can already do what you want,
you can already screw it up, you have root access. It has nothing to do
with the 'empowering the user' it more about the right the application
has to try and apply it's own rules for maintaining it's own internal
consistency, if you don't like that, you can fork the project, you can
download the source, you can change the behaviour, you already can do
what you want (including like you say weird and wonderful things with
LD_PRELOAD, making a copy etc. etc.)
> You want to throw away my bug reports because I have an extension that
> overrides the core? Fair enough (that's similar to Linux (the kernel)
> throwing away bug reports from tainted kernels, for example).
Huh? I don't see the comparison you wish to make, it's not like a 'user'
can install a kernel module anyway is it, you need to be an admin to do
that.
> You want to make me pay more for paid support because I have an
> extension that overrides the core? Fair enough.
no idea where your going