Hardcoded openid temp directory

[Georges Racinet]

This is seen on current trunk, although I remember it's not the first time I've come accross it:

OSError: [Errno 13] Permission denied: '/tmp/openerp-auth_openid-store/nonces'

Probably a hardcoded name for this directory leading to that error in multi-user environments.
If true the user name and numeric id should be used to provide robust user differentiation and continue to share accross several processes (e.g., Gunicorn) on the same box without resorting to session affinity.

[Olivier Dony (Odoo) (odo-openerp)]

Hi Georges,

The auth_openid module does not have any hardcoded directory, it's using the platform's temporary location, as appropriate.
You should not encounter any access rights issues in the creation or usage of the OpenID filestore directory, unless:
 - you have configured special access rights on the temporary directory on your platform (the user running OpenERP should be able to create files and directories inside it)
 - you are trying to run multiple OpenERP processes using different system users. This is not a supported configuration. Even in multiprocess deployments (GUnicorn etc..), all OpenERP processes are executed as the same user.

Note: let's not confuse the system user OpenERP is running as, and the users configured within each OpenERP database.
Perhaps you have executed the OpenERP server under different users while testing it? In that case you can simply delete the existing "/tmp/openerp-auth_openid-store" and restart the server.

If you want to run multiple OpenERP servers using different system users you are in unsupported territory (because OpenERP is designed as a multi-tenant platform, so it makes little sense). Nevertheless you can try one of the following:
 - On Unix: make sure they belong to the same Unix group, so they can read/write on each other's files in the temporary location (which by default should using a permission mask that gives the group the same permissions as the user)
 - Alternatively, configure an OS-level jail isolation for the processes, where each process has its own "/tmp" location

I hope this clarifies the topic a little bit...

[Christophe Combelles (ccomb)]

The bad line is in auth_openid/controllers/main.py:47:

_storedir = os.path.join(tempfile.gettempdir(), 'openerp-auth_openid-store')

It means that the openid store is shared between several system users, which might have security implications, as stated by the openid doc (openid/consumer/consumer.py)::

    Since the store does hold secrets shared between your application and the
    OpenID provider, you should be careful about how you use it in a shared
    hosting environment. If the filesystem or database permissions of your
    web host allow strangers to read from them, do not store your data there!
    If you have no safe place to store your data, construct your consumer
    with C{None} for the store, and it will operate only in stateless mode.
    Stateless mode may be slower, put more load on the OpenID provider, and
    trusts the provider to keep you safe from replay attacks.

I'm not sure just now how to fix this for a multiprocess gunicorn environment, but it should be doable.

I would definitely not classify this issue as invalid because it prevents OpenERP from working as expected in a multiuser environment as any unix application.

[Christophe Combelles (ccomb)]

There may be a workaround with environment variables, that can be done at startup time :
http://docs.python.org/library/tempfile.html#tempfile.tempdir

[Georges Racinet (gracinet)]

@ccomb: thanks for confirmation. About sharing between gunicorn processes, it's the same as it's done in the main wsgi handler (see #1035214) make the name of that temporary directory depend on system user information.

By the way, a clean workaround is to use the TMPDIR environment variable (see http://docs.python.org/library/tempfile.html) in the launching process (e.g from supervisor)

@odony: we have found so far only two problems with multi-system user environments, both being very simple to fix. We can definitely help supporting this cases. The other problem (#1035214) is minor relative to this one and even demonstrates that in a recent past, OpenERP did care about multi-system user concerns.

Use-cases for OpenERP running on a system on which it had at least previously run with another system user go far beyond hosting. For instance, a developer may want to run OpenERP installed from the official .deb package, and then from a custom built. I came accross the issue because I sometimes run some tests under a different system user on my workstation.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello,

I agree with Anybox guys: supporting multiple unix users shouldn't be too
hard and is fundamental for us integrators. For instance I may let a
trainee debug a development copy of a production server but not give access
to the production server itself. Using a different unix user is the easiest
way to achieve this.
On Sep 8, 2012 9:35 AM, "Georges Racinet" <email address hidden>
wrote:

> @ccomb: thanks for confirmation. About sharing between gunicorn
> processes, it's the same as it's done in the main wsgi handler (see
> #1035214) make the name of that temporary directory depend on system
> user information.
>
> By the way, a clean workaround is to use the TMPDIR environment variable
> (see http://docs.python.org/library/tempfile.html) in the launching
> process (e.g from supervisor)
>
> @odony: we have found so far only two problems with multi-system user
> environments, both being very simple to fix. We can definitely help
> supporting this cases. The other problem (#1035214) is minor relative to
> this one and even demonstrates that in a recent past, OpenERP did care
> about multi-system user concerns.
>
> Use-cases for OpenERP running on a system on which it had at least
> previously run with another system user go far beyond hosting. For
> instance, a developer may want to run OpenERP installed from the
> official .deb package, and then from a custom built. I came accross the
> issue because I sometimes run some tests under a different system user
> on my workstation.
>
> --
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenERP Web.
> https://bugs.launchpad.net/bugs/1040901
>
> Title:
> Hardcoded openid temp directory
>
> Status in OpenERP Web:
> Invalid
>
> Bug description:
> This is seen on current trunk, although I remember it's not the first
> time I've come accross it:
>
> OSError: [Errno 13] Permission denied: '/tmp/openerp-auth_openid-
> store/nonces'
>
> Probably a hardcoded name for this directory leading to that error in
> multi-user environments.
> If true the user name and numeric id should be used to provide robust
> user differentiation and continue to share accross several processes (e.g.,
> Gunicorn) on the same box without resorting to session affinity.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openerp-web/+bug/1040901/+subscriptions
>

[Georges Racinet (gracinet)]

Sorry, this is actually in openobject-addons. I just submitted a patch. It is simple enough, could you be so nice to reconsider ?

[Olivier Dony (Odoo) (odo-openerp)]

Georges' patch was merged in trunk some time ago[1], updating status. Thanks for the contribution!

[1] rev.7890 revid:gracinet@purity-20120914081101-4bx5yi8fxrlbav1r