openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

On Tue, Oct 15, 2013 at 10:17 AM, Brendan Clune <
brendan.clune@xxxxxxxxxxxxxxx> wrote:

> I agree.  A database user is a better choice in this instance since it is
> easier to understand the effective permissions of that user. I think it is
> dangerous to encourage queries at the ORM level that bypass all safety
> checks the ORM provides. If we do this, we then have very little idea what
> a user can and cannot do via XMLRPC. Raw SQL can be extremely useful but
> also very dangerous. By creating a separate database user, you _explicitly_
> define that user's level of access to the database. Thus, there is no
> surprise when an intern accidentally drops the entire database because you
> handed him a root PostgreSQL account. :)
>


Hello,

Well, I may not be shocked by such a method to execute raw SQL restricted
to only the admin user credentials. In fact today an admin user can already
access any data he wants on OpenERP: he can add menus and view to any
objects he wants and even edit RML or mako templates to perform arbitrary
malicious evals inside when they are not sandboxed template (getting safer
on trunk apparently).
So if it's restricted to the admin usage, it doesn't allow privilege
escalation over the current situation, it can only encourage bad practices
eventually. On the other side that can be handy to speed up a few requests
the ORM is currently not good at. In general I advise using client libs
such as erpeek or OOOR, but these could even take advantage of such an API
to speed up heavy operations under admin credentials in exceptional
situations.
Speaking about that, do we finally have a single RPC read+search entry
point method on trunk or will we still pay the latency+marshalling of two
requests?


My 0.2 BRL


-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com