auth_token middleware has too much state

Bug #1036847 reported by David Kranz
This bug affects 6 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)

Bug Description

I was trying to install swift to use keystone. This requires installing keystone to use the auth_token middleware. I got this error when the proxy server tried to start. There are a few problems with this code. First, this kind of software should never be using $HOME for anything. Second, it should probably not be creating directories. If it must do so, the code needs to defend itself against race conditions with other processes that might be using the same middleware. Checking if a directory exists and then trying to create it is not correct. I don't know what signing_dir is or if it is required but it is not in the sample conf file at all.

Traceback (most recent call last):
  File "/usr/local/bin/swift-proxy-server", line 22, in <module>
    run_wsgi(conf_file, 'proxy-server', default_port=8080, **options)
  File "/usr/local/lib/python2.7/dist-packages/swift/common/", line 133, in run_wsgi
    loadapp('config:%s' % conf_file, global_conf={'log_name': log_name})
  File "/usr/lib/python2.7/dist-packages/paste/deploy/", line 247, in loadapp
    return loadobj(APP, uri, name=name, **kw)
  File "/usr/lib/python2.7/dist-packages/paste/deploy/", line 272, in loadobj
    return context.create()
  File "/usr/lib/python2.7/dist-packages/paste/deploy/", line 710, in create
    return self.object_type.invoke(self)
  File "/usr/lib/python2.7/dist-packages/paste/deploy/", line 207, in invoke
    app = filter(app)
  File "/usr/lib/python2.7/dist-packages/keystone/middleware/", line 676, in auth_filter
    return AuthProtocol(app, conf)
  File "/usr/lib/python2.7/dist-packages/keystone/middleware/", line 167, in __init__
  File "/usr/lib/python2.7/", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/root/keystone-signing'

Revision history for this message
David Kranz (david-kranz) wrote :

It would also be nice were stand-alone so that you don't have to install all of keystone. The swift docs actually say that it is stand-alone and that you can just put in on your python path but that doesn't work because it imports other stuff from keystone.

Revision history for this message
Joseph Heck (heckj) wrote :

Hey David,

The auth_token pieces in the latest keystone recently added support for token PKI signing, which this looks to be running afoul of. The directory where it can find the signing pieces is configurable, with a default of the $HOME directly to provide some useful default that was coordinated with downstream packagers (Ubuntu, RedHat)

I believe the issue you're seeing is primarily related to not having a correct configuration in place. Could you provide some of the information related to how you've configured auth_token with swift?

Changed in keystone:
status: New → Incomplete
importance: Undecided → High
Revision history for this message
David Kranz (david-kranz) wrote :

There are several issues here. The reason I said library code should never user HOME is that a server may be set up to run as a user with no home directory. This is in fact how swift is set up by the Ubuntu package. I had no configuration for this so if my configuration is incorrect that means the Ubuntu configuration is incorrect. But you said they agreed to this default. In any event, if there are default config values that might not work that should be documented somehow. But I was using pre-release code so I accepted the risk :).

Revision history for this message
michealhua (michealhua) wrote :

Hi David,I meet the same situation,and do you find any solution now?I will waiting for your reply.

Revision history for this message
David Kranz (david-kranz) wrote :

I added a non-default value for 'signing_dir' in the [filter:authtoken]
 section of proxy-server.conf that is writable by the proxy server process.

Revision history for this message
michealhua (michealhua) wrote :

yeah,it said Permission denied,I added 'signing_dir=/etc/swift' in the [filter:authtoken] section of proxy-server.conf.However,that post

“File "/usr/local/lib/python2.7/dist-packages/keystone-2012.2-py2.7.egg/keystone/middleware/", line 216, in __init__
keystone.middleware.auth_token.ConfigurationError: unable to access signing dir /etc/swift”

And how do you set the 'signing_dir' in proxy-server.conf,and I find '[signing]' in keystone.conf.Thanks!

Revision history for this message
Joseph Heck (heckj) wrote :

Hi Michael -

First make sure that the process running the swift proxy has access to read and write /etc/swift,

Then update the /etc/swift/proxy-server.conf file to include that signing dir - something likeL

    paste.filter_factory = keystone.middleware.auth_token:filter_factory
    # Delaying the auth decision is required to support token-less
    # usage for anonymous referrers ('.r:*') or for tempurl/formpost
    # middleware.
    delay_auth_decision = 1
    auth_port = 35357
    auth_host =
    auth_token = ADMIN
    admin_token = ADMIN
    signing_dir = /etc/swift

Revision history for this message
David Medberry (med) wrote :

This also seems to effect Ubuntu f3 packages from their cloud archive. Unclear how to denote that.

Revision history for this message
Ryan Finnie (fo0bar) wrote :

Ditto, just encountered this in the version in ubuntu-cloud archive. Setting signing_dir explicitly fixes it.

Changed in keystone:
status: Incomplete → New
Revision history for this message
Adam Young (ayoung) wrote :

The proper place to put the files required by PKI signing is /var/cache/<service> not in /etc. Files in /etc should be configuration files, and owned by root, although readable by the applications. The certificates will be pulled down on demand, and we want to know ahead of time if the sepcified directory exists and is writable, so we fail at application load time as opposed to later. This means that even if you are not anticipating using PKI tokens, you application is capable of doing so if a PKI token is presented.

Sewtting signing_dir explicitly is pretty much required for all packaged versions of Openstack, but there is no way to affect all the changes required completely within Keystone. The $HOME solution was specifically for a safe default. It makes things easy for developers, but it also would be acceptable for a case where the system has a keystone user, and runs keystone as that services, assuming of course that the keystone user has a home directory.

Adam Young (ayoung)
Changed in keystone:
status: New → Invalid
Revision history for this message
HuaHero (huahero-long) wrote :

it's interesting that I use the #7 and add the last line,then it solved the problem

Revision history for this message
Alan Pevec (apevec) wrote :

FWIW current default in authtoken is tempfile.mkdtemp(prefix='keystone-signing-') so best is not to set signing_dir parameter and leave to authtoken to generate a tempdir which should be safe and secure.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers