PostgreSQL backend - Ident authentication failed?
Victor Hooi
We have a Django application that we just moved from a Ubuntu 9.04
server to 10.04. We're running Apache 2.2/WSGI, with PostgreSQL as the
backend.
My settings.py file:
'DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2', # Add
'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'NAME': 'mediatracking', # Or path to
database file if using sqlite3.
# os.path.join(PROJECT_PATH, "templates"),
'USER': 'victorhooi', # Not used with
sqlite3.
'PASSWORD': 'ourpassword', # Not used
with sqlite3.
'HOST': '', # Set to empty string for
localhost. Not used with sqlite3.
'PORT': '', # Set to empty string for
default. Not used with sqlite3.
}
}
I created a blank PostgreSQL database as myself ("victorhooi").
I ran ./manage.py syncdb, and this seemed to authenticate fine, and
create all the required tables.
When I try to go to http://site.com/admin though, I get an error:
OperationalError at /admin/
FATAL: Ident authentication failed for user "victorhooi"
I've read elsewhere that you need to do some tom-foolery to disable
ident authentication in PostgreSQL, or something. However, I'm
confused, because:
1. This exact same configuration seemed to work fine on our old
server.
2. The syncdb command works, but actually serving the web page
doesn't.
3. In the error message, it says ident authentication failed for user
"victorhooi", but that's the righ username to authenticate with, isn't
it?
I did notice further down in the error page, under settings:
CSRF_FAILURE_VIEW 'django.views.csrf.csrf_failure'
DATABASES {'default': 'ENGINE':
'django.db.backends.postgresql_psycopg2', 'HOST': '', 'NAME':
'mediatracking', 'OPTIONS': {}, 'PASSWORD': '********************',
'PORT': '', 'TEST_CHARSET': None, 'TEST_COLLATION': None,
'TEST_MIRROR': None, 'TEST_NAME': None, 'TIME_ZONE': 'Australia/
Sydney', 'USER': 'victorhooi'}}
DATABASE_ENGINE ''
DATABASE_HOST ''
DATABASE_NAME ''
DATABASE_OPTIONS {}
DATABASE_PASSWORD '********************'
DATABASE_PORT ''
DATABASE_ROUTERS []
DATABASE_USER ''
DATETIME_FORMAT 'N j, Y, P'
DATETIME_INPUT_FORMATS ('%Y-%m-%d %H:%M:%S', '%Y-%m-%d %H:%M'
Any suggestions?
Cheers,
Victor
Torsten Bronger
Victor Hooi writes:
> [...]
>
> I created a blank PostgreSQL database as myself ("victorhooi").
>
> I ran ./manage.py syncdb, and this seemed to authenticate fine,
> and create all the required tables.
>
> When I try to go to http://site.com/admin though, I get an error:
>
> OperationalError at /admin/
> FATAL: Ident authentication failed for user "victorhooi"
Does the webserver also run as victorhooi? Maybe it runs as
www-data for example.
Tsch�,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
Victor Hooi
Thanks for the tip. It does work now, following your advice =).
I created a new PostgreSQL user named "www-data". I then changed my
settings.py file:
'USER': 'www-data', # Not used with
'PASSWORD': 'ourpassword', # Not used
with sqlite3.
'HOST': '', # Set to empty string for
localhost. Not used with sqlite3.
'PORT': '', # Set to empty string for
default. Not used with sqlite3.
}
setup worked on the old Ubuntu 9.04 server? And I'm definitely sure
that the database username was set to "victorhooi" on that old system
- I copied the settings.py file over using verbatim (rsync).
Also, is this recommended practice, to use "www-data" as the backend
database username?
Cheers,
Victor
On Jun 21, 3:54 pm, Torsten Bronger <bron...@physik.rwth-aachen.de>
wrote:
>
> Victor Hooi writes:
> > [...]
>
> > I created a blank PostgreSQL database as myself ("victorhooi").
>
> > I ran ./manage.py syncdb, and this seemed to authenticate fine,
> > and create all the required tables.
>
> > OperationalError at /admin/
> > FATAL: Ident authentication failed for user "victorhooi"
>
> Does the webserver also run as victorhooi? Maybe it runs as
> www-data for example.
>
> Tsch ,
> Torsten.
>
> --
> Torsten Bronger, aquisgrana, europa vetus
> orhttp://bronger-jmp.appspot.com
Kenneth Gonsalves
> OperationalError at admin
> FATAL: Ident authentication failed for user "victorhooi"
>
in pg_hba.conf change the authorisation from ident to password
--
Regards
Kenneth Gonsalves
Senior Associate
NRC-FOSS at AU-KBC
Torsten Bronger
Victor Hooi writes:
> [...]
>
> However, I'm still curious as to what changed, as I'm fairly sure
> this setup worked on the old Ubuntu 9.04 server? And I'm
> definitely sure that the database username was set to "victorhooi"
> on that old system - I copied the settings.py file over using
> verbatim (rsync).
Maybe pg_hba.conf has changed.
> Also, is this recommended practice, to use "www-data" as the
> backend database username?
No, not recommended, but not forbidden either. We didn't use
"ident" but "password" in pg_hba.conf. This way, you are not bound
to user accounts of the underlying operating system.
But possibly we switch to "ident" for local connections
(i.e. command line) and "password" for TCP/IP connections. The
reason is that passwords make command line scripting harder.
Tsch�,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
Kenneth Gonsalves
> > Also, is this recommended practice, to use "www-data" as the
> > backend database username?
>
> No, not recommended, but not forbidden either.
>
should be forbidden - one does not want apache to have direct access to the
database
Victor Hooi
Using "www-data" as the backend database username in settings.py
doesn't quite work. If you try to run a ./manage.py syncdb, it spits
out:
Traceback (most recent call last):
File "./manage.py", line 11, in <module>
execute_manager(settings)
File "/usr/local/lib/python2.6/dist-packages/django/core/
management/__init__.py", line 438, in execute_manager
utility.execute()
File "/usr/local/lib/python2.6/dist-packages/django/core/
management/__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python2.6/dist-packages/django/core/
management/base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/local/lib/python2.6/dist-packages/django/core/
management/base.py", line 220, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.6/dist-packages/django/core/
management/base.py", line 351, in handle
return self.handle_noargs(**options)
File "/usr/local/lib/python2.6/dist-packages/django/core/
management/commands/syncdb.py", line 52, in handle_noargs
cursor = connection.cursor()
File "/usr/local/lib/python2.6/dist-packages/django/db/backends/
__init__.py", line 75, in cursor
cursor = self._cursor()
File "/usr/local/lib/python2.6/dist-packages/django/db/backends/
postgresql_psycopg2/base.py", line 136, in _cursor
self.connection = Database.connect(**conn_params)
psycopg2.OperationalError: FATAL: Ident authentication failed for
user "www-data"
I've changed the authentication in my pg_hba.conf from "ident" to
"password", and it now works with "victorhooi" as the backend database
username =). So there's no need to use a PostgreSQL www-data account.
I'm still curious what changed? Perhaps Ubuntu's default pg_hba.conf
file changed from 9.04 to 10.04? AFAIK, there wasn't any such change,
although I don't have a 9.04 system around to verify.
Anyhow, is this the recommended configuration, what I have now? Just
want to know the right way of doing things?
Cheers,
Victor
On Jun 21, 4:54 pm, Torsten Bronger <bron...@physik.rwth-aachen.de>
wrote:
> orhttp://bronger-jmp.appspot.com
Kenneth Gonsalves
> I'm still curious what changed? Perhaps Ubuntu's default pg_hba.conf
>
default always has ident in all distros that I am aware of
Sam Lai
> On Monday 21 June 2010 12:24:58 Torsten Bronger wrote:
>> > Also, is this recommended practice, to use "www-data" as the
>> > backend database username?
>>
>> No, not recommended, but not forbidden either.
>>
>
> should be forbidden - one does not want apache to have direct access to the
> database
Storing a password in plaintext file makes me uneasy, even though it
is locked away through file-system permissions.
Having spent some time recently in the Windows world, I take
integrated auth for granted, and it works fine, making sysadmin much
easier.
You do bring up a interesting point though, and I don't know much
about the architecture of Apache and how holes are exploited when they
exist, but if the trespasser can execute arbitary code as www-data,
wouldn't they have access to settings.py anyway?
> --
> Regards
> Kenneth Gonsalves
> Senior Associate
> NRC-FOSS at AU-KBC
>
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>
Kenneth Gonsalves
> > should be forbidden - one does not want apache to have direct access to
> > the database
>
> Storing a password in plaintext file makes me uneasy, even though it
> is locked away through file-system permissions.
>
> Having spent some time recently in the Windows world, I take
> integrated auth for granted, and it works fine, making sysadmin much
> easier.
and a single point of entry to all systems for a cracker
>
> You do bring up a interesting point though, and I don't know much
> about the architecture of Apache and how holes are exploited when they
> exist, but if the trespasser can execute arbitary code as www-data,
> wouldn't they have access to settings.py anyway?
>
and just to add to your worries, assuming that you have debug on in your
production system, somewhere deep down in the traceback, you may see your
database username and password! As for the apache question there are experts
in this list who can anwer them.
Sam Lai
> On Monday 21 June 2010 13:39:42 Sam Lai wrote:
>> > should be forbidden - one does not want apache to have direct access to
>> > the database
>>
>> Storing a password in plaintext file makes me uneasy, even though it
>> is locked away through file-system permissions.
>>
>> Having spent some time recently in the Windows world, I take
>> integrated auth for granted, and it works fine, making sysadmin much
>> easier.
>
> and a single point of entry to all systems for a cracker
I'm not running them all as admin (aka. root) obviously. Integrated
auth doesn't mean every user account can access every resource. It's
really just delegating an application's authentication system to the
operating system (note authentication, not authorization).
I fail to see how it is a single-point of entry to all systems. Yes,
it means there's one less layer of security, but that extra layer
provided by the DBMS isn't security anyway if as that OS user, you can
access the password to get past that extra layer of security anyway. I
don't believe this is an implementation of defense in depth.
>> You do bring up a interesting point though, and I don't know much
>> about the architecture of Apache and how holes are exploited when they
>> exist, but if the trespasser can execute arbitary code as www-data,
>> wouldn't they have access to settings.py anyway?
>>
>
> and just to add to your worries, assuming that you have debug on in your
> production system, somewhere deep down in the traceback, you may see your
> database username and password! As for the apache question there are experts
> in this list who can anwer them.
Thanks for mocking what was and still is a serious point.
> --
> Regards
> Kenneth Gonsalves
> Senior Associate
> NRC-FOSS at AU-KBC
>
Kenneth Gonsalves
> > and a single point of entry to all systems for a cracker
>
> I'm not running them all as admin (aka. root) obviously. Integrated
> auth doesn't mean every user account can access every resource. It's
> really just delegating an application's authentication system to the
> operating system (note authentication, not authorization).
>
> I fail to see how it is a single-point of entry to all systems. Yes,
> it means there's one less layer of security, but that extra layer
> provided by the DBMS isn't security anyway if as that OS user, you can
> access the password to get past that extra layer of security anyway. I
> don't believe this is an implementation of defense in depth.
I am no expert on windows, so cannot comment.
>
> >> You do bring up a interesting point though, and I don't know much
> >> about the architecture of Apache and how holes are exploited when they
> >> exist, but if the trespasser can execute arbitary code as www-data,
> >> wouldn't they have access to settings.py anyway?
> >
> > and just to add to your worries, assuming that you have debug on in your
> > production system, somewhere deep down in the traceback, you may see your
> > database username and password! As for the apache question there are
> > experts in this list who can anwer them.
>
> Thanks for mocking what was and still is a serious point.
>
I am sorry if you feel I was mocking - it was not my intention. And the point
you were bringing up about Apache is a vast subject and I am not competent to
answer it. As for the debug thing, it is just a warning not to run debug in
production.
Sam Lai
Ah I must've interpreted it incorrectly, I apologise. I'm definitely
no expert on *nix and Apache security, so I'd appreciate it if anyone
could clarify as well.
From the PGSQL docs [1],
"On systems supporting SO_PEERCRED requests for Unix-domain sockets
(currently Linux, FreeBSD, NetBSD, OpenBSD, BSD/OS, and Solaris),
ident authentication can also be applied to local connections. In this
case, no security risk is added by using ident authentication; indeed
it is a preferable choice for local connections on such systems."
http://www.postgresql.org/docs/current/static/auth-methods.html
So it seems the postgresql people think it is ok, but I'm not sure
once you add in Apache and things like Django on top of it.
> --
> Regards
> Kenneth Gonsalves
> Senior Associate
> NRC-FOSS at AU-KBC
>
Kenneth Gonsalves
> >From the PGSQL docs [1],
>
> "On systems supporting SO_PEERCRED requests for Unix-domain sockets
> (currently Linux, FreeBSD, NetBSD, OpenBSD, BSD/OS, and Solaris),
> ident authentication can also be applied to local connections. In this
> case, no security risk is added by using ident authentication; indeed
> it is a preferable choice for local connections on such systems."
>
> http://www.postgresql.org/docs/current/static/auth-methods.html
>
> So it seems the postgresql people think it is ok, but I'm not sure
> once you add in Apache and things like Django on top of it.
>
I am not too sure whether connection over tcp/ip comes under 'local'