How to deny user changing his own password?

adeon wrote:

Hi

My question is in subject.
How can I deny user changing his own password using
ALTER USER user WITH PASSWORD 'password'; ?

AFAIK you can't, IMHO you shouldn't anyway and I would object
against such useless feature.

Jan

Thanks
adeon

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Now I think about this it would be useful: I have an Access database which
connects to postgres and the password is saved in the access frontend. If
someone (not sure how!) runs ALTER USER ..... WITH PASSWORD '....'; via the
frontend they could disrupt the connection to the postgres backend. I'm
sure a similar situation could happen with PHP or similar as you often don't
use the postgres security features to secure your application.

Regards,

Ben Trewern

-----Original Message-----
From: Jan Wieck [mailto:JanWieck@Yahoo.com]
Sent: 29 May 2003 14:52
To: adeon
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] How to deny user changing his own password?

adeon wrote:

Hi

My question is in subject.
How can I deny user changing his own password using
ALTER USER user WITH PASSWORD 'password'; ?

AFAIK you can't, IMHO you shouldn't anyway and I would object against such
useless feature.

Jan

Thanks
adeon

---------------------------(end of
broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your message
can get through to the mailing list cleanly

*****************************************************************************
This email and any attachments transmitted with it are confidential
and intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the sender and do not store, copy or disclose the content
to any other person.

It is the responsibility of the recipient to ensure that opening this
message and/or any of its attachments will not adversely affect
its systems. No responsibility is accepted by the Company.
*****************************************************************************

Trewern, Ben wrote:

Now I think about this it would be useful: I have an Access database
which connects to postgres and the password is saved in the access
frontend. If someone (not sure how!) runs ALTER USER ..... WITH
PASSWORD '....'; via the frontend they could disrupt the connection to
the postgres backend. I'm sure a similar situation could happen with
PHP or similar as you often don't use the postgres security features to
secure your application.

This is the second worst possible reason I can imagine for a feature
like this. Passwords coded into the frontend ... gosh!

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

This is the second worst possible reason I can imagine for a feature
like this. Passwords coded into the frontend ... gosh!

Depending on the application, coding a password into the front end can
be a necessary condition. Think of a PHP web page script that makes
database calls. How are you going to prevent other unauthorized
connections from that system? Passwords aren't a perfect security
device, but they're generally better than no password.

I could see some merit to a 'LOCK' option on the alter user command, so that
the password can only be changed by a superuser.
--
Mike Nolan

On Thu, May 29, 2003 at 13:18:01 -0500,
nolan@celery.tssi.com wrote:

This is the second worst possible reason I can imagine for a feature
like this. Passwords coded into the frontend ... gosh!

Depending on the application, coding a password into the front end can
be a necessary condition. Think of a PHP web page script that makes
database calls. How are you going to prevent other unauthorized
connections from that system? Passwords aren't a perfect security
device, but they're generally better than no password.

You can use ident authentication.

I could see some merit to a 'LOCK' option on the alter user command, so that
the password can only be changed by a superuser.

That would only be useful if the account was shared, which is normally a bad
idea.

I was actually thinking the same thing. Typically the use for a web user runs a
system user with minimalistic permissions on the other hand, the **database**
user that any CGI scripts connect to the database as need permissions to the
database resources- two entirely different things.

Unless you choose to have different DB user for each application with a web
interface,
you might be faced with a serious problem if the DB user's account password gets
changed since that DB user's account is effectively used for several applications.

Quoting nolan@celery.tssi.com:

This is the second worst possible reason I can imagine for a feature
like this. Passwords coded into the frontend ... gosh!

Depending on the application, coding a password into the front end can
be a necessary condition. Think of a PHP web page script that makes
database calls. How are you going to prevent other unauthorized
connections from that system? Passwords aren't a perfect security
device, but they're generally better than no password.

I could see some merit to a 'LOCK' option on the alter user command, so that

the password can only be changed by a superuser.
--
Mike Nolan

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com

Bruno Wolff III <bruno@wolff.to> writes:

nolan@celery.tssi.com wrote:

I could see some merit to a 'LOCK' option on the alter user command, so that
the password can only be changed by a superuser.

That would only be useful if the account was shared, which is normally a bad
idea.

It'd seem to me that once a bad guy has gotten into your database,
whether he can change a password is the least of your worries.
The people you'd really want to be afraid of would not call attention
to their breakin by doing anything as blatantly obvious as that, anyway.

In short, I don't see any value in a password lock option either.
And ISTM anyplace that used it would be getting in the way of good
password management practice. Users *should* be encouraged to change
their own passwords, and to do so regularly.

regards, tom lane

On Thu, May 29, 2003 at 05:36:04PM +0100, Trewern, Ben wrote:

Now I think about this it would be useful: I have an Access database which
connects to postgres and the password is saved in the access frontend. If
someone (not sure how!) runs ALTER USER ..... WITH PASSWORD '....'; via the
frontend they could disrupt the connection to the postgres backend. I'm
sure a similar situation could happen with PHP or similar as you often don't
use the postgres security features to secure your application.

Not sure with Access, but in general when running something backed by a
database you should not just allow arbitrary SQL reach the database.
There should be no way for any user of the application to execute an
ALTER USER query.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Before you were born your parents weren't as boring as they are now. They
got that way paying your bills, cleaning up your room and listening to you
tell them how idealistic you are." -- Charles J. Sykes' advice to teenagers

In short, I don't see any value in a password lock option either.

It seems to me that if I can give a user 'read only' access to a database,
I should be able to give 'read only' access in every aspect, including
locking down the password.

And ISTM anyplace that used it would be getting in the way of good
password management practice. Users *should* be encouraged to change
their own passwords, and to do so regularly.

No real argument there, but is an application a 'user' in the ordinary
sense of the word? Would you, as DBA, prefer a locked-down password or
one that you might have to change in dozens of locations?

It seems me that the underlying issue of how to authenticate access
from an 'outside' and compromiseable client may not be easily solveable.
Locking down the password falls under the category of 'damage control'.

('Inside' clients can be compromised too, of course.)

I'm not sure 'ident' solves the problem any better than an embedded password
does, and the documentation on ident raises this red flag:

This authentication method is therefore only appropriate for
closed networks where each client machine is under tight control
and where the database and system administrators operate in close
contact. In other words, you must trust the machine running the
ident server. Heed the warning:

The Identification Protocol is not intended as an authorization
or access control protocol. --RFC 1413
--
Mike Nolan

On Thu, May 29, 2003 at 17:09:18 -0500,
nolan@celery.tssi.com wrote:

I'm not sure 'ident' solves the problem any better than an embedded password
does, and the documentation on ident raises this red flag:

If you want to run applications that connect to your DB from untrusted
hosts there probably isn't any good solution. If you are connecting from
untrusted networks, than you may want to set up an authenticated tunnel
which you can then use for connecting to the DB.
However, neither of these are the normal case.

Ident authentication is better than password authentication because it is
bound to the machine. Someone can't change it out from under or take it with
them to use from another machine.

This authentication method is therefore only appropriate for
closed networks where each client machine is under tight control
and where the database and system administrators operate in close
contact. In other words, you must trust the machine running the
ident server. Heed the warning:

The Identification Protocol is not intended as an authorization
or access control protocol. --RFC 1413

Note that for applications running on the DB server you don't have to use
an RFC 1413 server. On server common operating systems you can find out
the user id of the process connecting to you via domain sockets. This is
as good as whatever the user used to authenticate to the OS.