ALTER USER
Hackers,
One can alter a user to set a validity timestamp. However, unless one
uses the ugly kludge of setting a date very far into the future, there's
no way to set this validity forever.
Should I make a patch to correct this? Should be quite trivial.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El dia que dejes de cambiar dejaras de vivir"
On Sat, Mar 15, 2003 at 22:38:13 -0400,
Alvaro Herrera <alvherre@dcc.uchile.cl> wrote:
Hackers,
One can alter a user to set a validity timestamp. However, unless one
uses the ugly kludge of setting a date very far into the future, there's
no way to set this validity forever.
There is an infinite time for timestamp. There currently isn't for date,
though there was some talk about doing that.
On Sun, Mar 16, 2003 at 07:37:26AM -0600, Bruno Wolff III wrote:
On Sat, Mar 15, 2003 at 22:38:13 -0400,
Alvaro Herrera <alvherre@dcc.uchile.cl> wrote:Hackers,
One can alter a user to set a validity timestamp. However, unless one
uses the ugly kludge of setting a date very far into the future, there's
no way to set this validity forever.There is an infinite time for timestamp. There currently isn't for date,
though there was some talk about doing that.
I don't know much about date/time datatypes, but valuntil is of type
abstime, and you can set it to infinity:
alvh=# alter user alvh valid until 'infinity';
ALTER USER
alvh=# select usename, valuntil from pg_shadow where usename='alvh';
usename | valuntil
---------+----------
alvh | infinity
(1 row)
I see now that one can use this syntax to make a user valid forever,
though it is different than setting the value to NULL (as is when the
user hasn't got a validity defined). This should be mentioned in the
docs, I think.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"In fact, the basic problem with Perl 5's subroutines is that they're not
crufty enough, so the cruft leaks out into user-defined code instead, by
the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6)
I see now that one can use this syntax to make a user valid forever,
though it is different than setting the value to NULL (as is when the
user hasn't got a validity defined). This should be mentioned in the
docs, I think.
It may be worth while to change the default for valuntil to be
'infinity'. NULL implies they will expire, we're just not sure when.
Infinity shows that we do not intend to expire the user -- which is more
in-line with the actual implementation.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
Rod Taylor <rbt@rbt.ca> writes:
It may be worth while to change the default for valuntil to be
'infinity'. NULL implies they will expire, we're just not sure when.
This is not the only place in the system catalogs where NULL is
effectively used to mean a default value that could also be spelled
out explicitly. (ACLs behave that way, and useconfig/datconfig
do too IIRC.)
It's a bit of a hack, but it saves table space and backend code ---
without this convention the default would have to be inserted "manually"
since we have no mechanism to supply defaults when C code is forming a
new catalog tuple.
I'm inclined to leave the code alone. But Alvaro is right that it'd be
good to point out the 'infinity' option in the CREATE USER and ALTER
USER man pages. (Doc patch please?)
regards, tom lane
On Sun, Mar 16, 2003 at 12:36:25PM -0500, Tom Lane wrote:
I'm inclined to leave the code alone. But Alvaro is right that it'd be
good to point out the 'infinity' option in the CREATE USER and ALTER
USER man pages. (Doc patch please?)
Attached. (Please correct if it's not good english.)
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Investigaci�n es lo que hago cuando no s� lo que estoy haciendo"
(Wernher von Braun)
Attachments:
alter-user-doc.patchtext/plain; charset=us-asciiDownload
Index: doc/src/sgml/ref/alter_user.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/ref/alter_user.sgml,v
retrieving revision 1.24
diff -c -r1.24 alter_user.sgml
*** doc/src/sgml/ref/alter_user.sgml 2003/01/19 00:13:29 1.24
--- doc/src/sgml/ref/alter_user.sgml 2003/03/16 17:57:31
***************
*** 124,130 ****
<listitem>
<para>
The date (and, optionally, the time)
! at which this user's password is to expire.
</para>
</listitem>
</varlistentry>
--- 124,131 ----
<listitem>
<para>
The date (and, optionally, the time)
! at which this user's password is to expire. To set the password
! never to expire, use 'infinity'.
</para>
</listitem>
</varlistentry>
***************
*** 229,234 ****
--- 230,242 ----
the time zone which is one hour ahead of <acronym>UTC</>:
<programlisting>
ALTER USER chris VALID UNTIL 'May 4 12:00:00 1998 +1';
+ </programlisting>
+ </para>
+
+ <para>
+ Make a user valid forever:
+ <programlisting>
+ ALTER USER fred VALID UNTIL 'infinity';
</programlisting>
</para>
Is it just the password that expires or the account? The comment for
valid until says the password is valid until that time. However, one of
the examples says the account is valid until that time.
Bruno Wolff III <bruno@wolff.to> writes:
Is it just the password that expires or the account? The comment for
valid until says the password is valid until that time. However, one of
the examples says the account is valid until that time.
Given the current implementation, I think it's correct to say that
the password expires not the account:
1. the userid isn't deleted or anything like that.
2. validuntil is only checked in password authentication methods; if you
are able to connect via a non-password auth method (eg IDENT) then it's
not checked.
I've never been quite sure whether #2 is a bug or a feature, though.
regards, tom lane
1. the userid isn't deleted or anything like that.
2. validuntil is only checked in password authentication methods; if you
are able to connect via a non-password auth method (eg IDENT) then it's
not checked.I've never been quite sure whether #2 is a bug or a feature, though.
Without knowing the history, I would have assumed that this was added to be
the start of a 'password ageing' function. Similar fields exist in GCOS
passwd files, but very few systems use them.
I got bitten by this when some of my user account (in a 6.x DB) were
invalidated after two years. Like I remembered to check...
Peter
I am a little disturbed by having NULL mean no expire of password, but
documenting that 'infinity' is the proper way to set no expiration.
Does that disturb anyone else? Should we hack up the grammar to allow
VALID UNTIL NULL for consistency?
I guess I imagine someone spinning through pg_shadow and looking for
infinity and not looking at NULL as equivalent. Maybe I should document
NULL is valid too for 'infinity'.
I will apply Alvero's documentation patch with a mention that internally
NULL is also infinity.
Comments?
---------------------------------------------------------------------------
Tom Lane wrote:
Rod Taylor <rbt@rbt.ca> writes:
It may be worth while to change the default for valuntil to be
'infinity'. NULL implies they will expire, we're just not sure when.This is not the only place in the system catalogs where NULL is
effectively used to mean a default value that could also be spelled
out explicitly. (ACLs behave that way, and useconfig/datconfig
do too IIRC.)It's a bit of a hack, but it saves table space and backend code ---
without this convention the default would have to be inserted "manually"
since we have no mechanism to supply defaults when C code is forming a
new catalog tuple.I'm inclined to leave the code alone. But Alvaro is right that it'd be
good to point out the 'infinity' option in the CREATE USER and ALTER
USER man pages. (Doc patch please?)regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Alvaro Herrera wrote:
On Sun, Mar 16, 2003 at 12:36:25PM -0500, Tom Lane wrote:
I'm inclined to leave the code alone. But Alvaro is right that it'd be
good to point out the 'infinity' option in the CREATE USER and ALTER
USER man pages. (Doc patch please?)Attached. (Please correct if it's not good english.)
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Investigaci?n es lo que hago cuando no s? lo que estoy haciendo"
(Wernher von Braun)
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Patch applied. Thanks.
---------------------------------------------------------------------------
Alvaro Herrera wrote:
On Sun, Mar 16, 2003 at 12:36:25PM -0500, Tom Lane wrote:
I'm inclined to leave the code alone. But Alvaro is right that it'd be
good to point out the 'infinity' option in the CREATE USER and ALTER
USER man pages. (Doc patch please?)Attached. (Please correct if it's not good english.)
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Investigaci?n es lo que hago cuando no s? lo que estoy haciendo"
(Wernher von Braun)
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073