Thread: BUG #6264: Superuser does not have inherent Replication permission
The following bug has been logged online: Bug reference: 6264 Logged by: Keith Fiske Email address: keith@omniti.com PostgreSQL version: 9.1.1 Operating system: Debian Description: Superuser does not have inherent Replication permission Details: Was testing out an upgrade from 9.0.4 to 9.1.1 and ran across either some lack of clarity in the documentation or a bug in the superuser privilege. I had a streaming replication setup and after the upgrade and setting up the new slave, the slave would no longer connect to the master for SR. Looking into this more, I saw that 9.1 has a new Replication permission to allow non-superusers the ability to be replication users. The documentation says replication is inherent to a superuser. After testing several times, I can assure you it is not. The old replication user from 9.0.4 which was carried through the upgrade kept its superuser privileges, but was unable to be used for replication until I explicitly granted it the Replication permission. Brand new roles created initially as superusers are explicitly given the separate replication permission. If you create a user as a NONsuperuser, then later ALTER them to be one, they will NOT have the replication permission and cannot be used as a replication user until you explicitly grant that permission.
"Keith Fiske" <keith@omniti.com> writes: > The documentation says replication is inherent to a superuser. What it actually says is that superusers get the replication privilege by default --- but you can create a superuser without that. If you see a place that says something different, please point it out specifically so we can improve it. > After testing > several times, I can assure you it is not. Please show your test case. It looks to me like it works as expected: regression=# create user foo superuser; CREATE ROLE regression=# create user foo2 superuser noreplication; CREATE ROLE regression=# select rolname,rolsuper,rolreplication from pg_authid ; rolname | rolsuper | rolreplication ----------+----------+---------------- postgres | t | t foo | t | t foo2 | t | f (3 rows) > If you create a user as a NONsuperuser, > then later ALTER them to be one, they will NOT have the replication > permission and cannot be used as a replication user until you explicitly > grant that permission. That doesn't sound to me like a bug. These flags are independent, we just provide a certain default at role creation time. regards, tom lane
On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Keith Fiske" <keith@omniti.com> writes: >> The documentation says replication is inherent to a superuser. > > What it actually says is that superusers get the replication privilege > by default --- but you can create a superuser without that. =A0If you > see a place that says something different, please point it out > specifically so we can improve it. =46rom the documentation "...If not specified, NOREPLICATION is the default for all roles except superusers..." =46rom the 9.1 release notes: "...Previously only superusers could initiate replication connections; superusers still have this permission by default..." Reading through all the other options, none of them state anything special about superuser defaults. As stated above, if one were first reading this, one would assume that a superuser would have replication permission as default, no matter if it was given superuser via ALTER ROLE or CREATE ROLE. If you're going to start saying which permissions a superuser has and doesn't have by default, you should be consistent with all of them and clearly state how and when they are given. Ex: superusers inherently have CREATEROLE and CREATEDB, but not LOGIN. And especially reading the release notes the use of the word "still" would indicate that it works the same as it did in 9.0. It's what caused my much of my confusion in this whole thing. When I upgraded my 9.0.4 system to 9.1 and couldn't get streaming replication to work, I saw the above and began to assume this was a regression of the "replication" role name issue since it gave the same error that that bug gave and things were working fine in 9.0.4. It was only after I created a brand new superuser and then did a \du that I noticed the replication permission was tacked on separately and only during role creation. An upgrade from 9.0 to 9.1 does not account for SR users and the release notes should probably reflect this, NOT state that superusers still have the permission by default. They don't. > >> After testing >> several times, I can assure you it is not. > > Please show your test case. =A0It looks to me like it works as expected: > > regression=3D# create user foo superuser; > CREATE ROLE > regression=3D# create user foo2 superuser noreplication; > CREATE ROLE > regression=3D# select rolname,rolsuper,rolreplication from pg_authid ; > =A0rolname =A0| rolsuper | rolreplication > ----------+----------+---------------- > =A0postgres | t =A0 =A0 =A0 =A0| t > =A0foo =A0 =A0 =A0| t =A0 =A0 =A0 =A0| t > =A0foo2 =A0 =A0 | t =A0 =A0 =A0 =A0| f > (3 rows) > > If you create a non-super user then ALTER them to be one, they don't have replication as default. This either needs to be clarified in the documentation or the ALTER should give the same defaults as the CREATE. Whether it's inherent like CREATEDB or a separate permission, I don't think matters and is a whole other argument. But things should be consistent in some manner. >> If you create a user as a NONsuperuser, >> then later ALTER them to be one, they will NOT have the replication >> permission and cannot be used as a replication user until you explicitly >> grant that permission. > > That doesn't sound to me like a bug. =A0These flags are independent, we > just provide a certain default at role creation time. > That is not what the documentation as read would lead people to believe. I'd be more than happy to help with clarifying the documentation myself if needed. Just let me know how. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, tom lane > -- Keith Fiske Database Administrator OmniTI Computer Consulting, Inc.
On Mon, Oct 24, 2011 at 16:37, Keith Fiske <keith@omniti.com> wrote: > On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> "Keith Fiske" <keith@omniti.com> writes: > >>> If you create a user as a NONsuperuser, >>> then later ALTER them to be one, they will NOT have the replication >>> permission and cannot be used as a replication user until you explicitly >>> grant that permission. >> >> That doesn't sound to me like a bug. =A0These flags are independent, we >> just provide a certain default at role creation time. >> > > That is not what the documentation as read would lead people to > believe. I'd be more than happy to help with clarifying the > documentation myself if needed. Just let me know how. This part I agree with - it makes sense for ALTER to set both flags when it enables superuser. It seems inconsistent now - even if it may be technically correct. If we don't change it, we should definitely accept a docs patch to clarify what happens, because I agree it's confusing. --=20 =A0Magnus Hagander =A0Me: http://www.hagander.net/ =A0Work: http://www.redpill-linpro.com/
On Tue, Oct 25, 2011 at 1:39 PM, Magnus Hagander <magnus@hagander.net> wrot= e: > On Mon, Oct 24, 2011 at 16:37, Keith Fiske <keith@omniti.com> wrote: >> On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> "Keith Fiske" <keith@omniti.com> writes: >> >>>> If you create a user as a NONsuperuser, >>>> then later ALTER them to be one, they will NOT have the replication >>>> permission and cannot be used as a replication user until you explicit= ly >>>> grant that permission. >>> >>> That doesn't sound to me like a bug. =A0These flags are independent, we >>> just provide a certain default at role creation time. >>> >> >> That is not what the documentation as read would lead people to >> believe. I'd be more than happy to help with clarifying the >> documentation myself if needed. Just let me know how. > > This part I agree with - it makes sense for ALTER to set both flags > when it enables superuser. +1 Change the behaviour to match the docs makes most sense to me. --=20 =A0Simon Riggs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http:/= /www.2ndQuadrant.com/ =A0PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Oct 25, 2011 at 8:39 AM, Magnus Hagander <magnus@hagander.net> wrot= e: > On Mon, Oct 24, 2011 at 16:37, Keith Fiske <keith@omniti.com> wrote: >> On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> "Keith Fiske" <keith@omniti.com> writes: >> >>>> If you create a user as a NONsuperuser, >>>> then later ALTER them to be one, they will NOT have the replication >>>> permission and cannot be used as a replication user until you explicit= ly >>>> grant that permission. >>> >>> That doesn't sound to me like a bug. =A0These flags are independent, we >>> just provide a certain default at role creation time. >>> >> >> That is not what the documentation as read would lead people to >> believe. I'd be more than happy to help with clarifying the >> documentation myself if needed. Just let me know how. > > This part I agree with - it makes sense for ALTER to set both flags > when it enables superuser. It seems inconsistent now - even if it may > be technically correct. > > If we don't change it, we should definitely accept a docs patch to > clarify what happens, because I agree it's confusing. There's a pre-existing catalog flag called rolcatupdate that works a little bit like this, and we discussed making rolreplication behave similarly. But we ended up with different semantics: rhaas=3D# create user bob nosuperuser; CREATE ROLE rhaas=3D# create user fred nosuperuser; CREATE ROLE rhaas=3D# alter role fred superuser; ALTER ROLE rhaas=3D# create user harry superuser; CREATE ROLE rhaas=3D# select * from pg_authid where rolname in ('bob', 'fred', 'harry') order by rolname; rolname | rolsuper | rolinherit | rolcreaterole | rolcreatedb | rolcatupdate | rolcanlogin | rolreplication | rolconnlimit | rolpassword | rolvaliduntil ---------+----------+------------+---------------+-------------+-----------= ---+-------------+----------------+--------------+-------------+-----------= ---- bob | f | t | f | f | f | t | f | -1 | | fred | t | t | f | f | t | t | f | -1 | | harry | t | t | f | f | t | t | t | -1 | | (3 rows) One difference is that, AFAIK, there's no DDL command to change rolcatupdate separately from rolsuper. If we do decide to change the behavior, we'd better carefully document that if you want to make someone a superuser without giving them replication privileges (or revoke their superuser status without revoking replication privileges), you need to specify both ALTER TABLE options. All in all I'm somewhat inclined to think we should just patch the docs. 9.1 hasn't been out for very long, so maybe expectations aren't too settled yet, but changing security-critical behavior in back branches doesn't seem like a wonderful idea; and I think I mildly prefer the current semantics to the proposed ones. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > ... If we do decide to change the > behavior, we'd better carefully document that if you want to make > someone a superuser without giving them replication privileges (or > revoke their superuser status without revoking replication > privileges), you need to specify both ALTER TABLE options. You'd also have to be careful about processing-order dependencies; consider ALTER USER joe NOREPLICATION SUPERUSER; which would do the wrong thing with a naive implementation. > All in all I'm somewhat inclined to think we should just patch the > docs. 9.1 hasn't been out for very long, so maybe expectations aren't > too settled yet, but changing security-critical behavior in back > branches doesn't seem like a wonderful idea; and I think I mildly > prefer the current semantics to the proposed ones. +1 regards, tom lane
On Thu, Oct 27, 2011 at 01:45:34PM -0400, Robert Haas wrote: > On Tue, Oct 25, 2011 at 8:39 AM, Magnus Hagander <magnus@hagander.net> wrote: > > On Mon, Oct 24, 2011 at 16:37, Keith Fiske <keith@omniti.com> wrote: > >> On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> "Keith Fiske" <keith@omniti.com> writes: > >> > >>>> If you create a user as a NONsuperuser, > >>>> then later ALTER them to be one, they will NOT have the replication > >>>> permission and cannot be used as a replication user until you explicitly > >>>> grant that permission. > >>> > >>> That doesn't sound to me like a bug. ?These flags are independent, we > >>> just provide a certain default at role creation time. > >>> > >> > >> That is not what the documentation as read would lead people to > >> believe. I'd be more than happy to help with clarifying the > >> documentation myself if needed. Just let me know how. > > > > This part I agree with - it makes sense for ALTER to set both flags > > when it enables superuser. It seems inconsistent now - even if it may > > be technically correct. > > > > If we don't change it, we should definitely accept a docs patch to > > clarify what happens, because I agree it's confusing. > > There's a pre-existing catalog flag called rolcatupdate that works a > little bit like this, and we discussed making rolreplication behave > similarly. But we ended up with different semantics: [ALTER ROLE sets rolcatupdate = rolsuper when changing rolsuper.] > One difference is that, AFAIK, there's no DDL command to change > rolcatupdate separately from rolsuper. If we do decide to change the > behavior, we'd better carefully document that if you want to make > someone a superuser without giving them replication privileges (or > revoke their superuser status without revoking replication > privileges), you need to specify both ALTER TABLE options. Let's look at the behavior of DDL-exposed access constraints for precedent. We currently have three paradigms for applying access control to superusers: 1. Settings that affect superusers and regular users identically. These include ALTER ROLE ... LOGIN | VALID UNTIL. 2. Rights that superusers possess implicitly and irrevocably; the actual setting recorded in pg_authid or elsewhere has no effect. These include GRANT ... ON TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. I think we should merge #3 into #2; nothing about the REPLICATION setting justifies a distinct paradigm. On a clean slate, #1 might be an equally suitable fit. However, #2 provides better backward compatibility with 9.0. > All in all I'm somewhat inclined to think we should just patch the > docs. 9.1 hasn't been out for very long, so maybe expectations aren't > too settled yet, but changing security-critical behavior in back > branches doesn't seem like a wonderful idea; and I think I mildly > prefer the current semantics to the proposed ones. The implication of my proposal is to remove the possibility of creating a superuser that cannot connect for replication; users so restricted under 9.1.1 would suddenly be able to make replication connections in 9.1.2. Of course, they could already "ALTER ROLE myself REPLICATION". On that account, no secure system would quietly become insecure following such an upgrade. nm
Noah Misch <noah@leadboat.com> writes: > Let's look at the behavior of DDL-exposed access constraints for precedent. We > currently have three paradigms for applying access control to superusers: > 1. Settings that affect superusers and regular users identically. These include > ALTER ROLE ... LOGIN | VALID UNTIL. > 2. Rights that superusers possess implicitly and irrevocably; the actual setting > recorded in pg_authid or elsewhere has no effect. These include GRANT ... ON > TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. > 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE > ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. > I think we should merge #3 into #2; nothing about the REPLICATION setting > justifies a distinct paradigm. Yeah, there's much to be said for that. I thought the notion of a privilege that superusers might not have was pretty bogus to start with. rolcatupdate isn't a very good precedent to rely on because it's never been documented or used to any noticeable extent, so there's no reason to think that it provides a tested-and-accepted behavior. regards, tom lane
On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Noah Misch <noah@leadboat.com> writes: >> Let's look at the behavior of DDL-exposed access constraints for precede= nt. =A0We >> currently have three paradigms for applying access control to superusers: > >> 1. Settings that affect superusers and regular users identically. =A0The= se include >> ALTER ROLE ... LOGIN | VALID UNTIL. > >> 2. Rights that superusers possess implicitly and irrevocably; the actual= setting >> recorded in pg_authid or elsewhere has no effect. =A0These include GRANT= ... ON >> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. > >> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE = ROLE >> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. > >> I think we should merge #3 into #2; nothing about the REPLICATION setting >> justifies a distinct paradigm. > > Yeah, there's much to be said for that. =A0I thought the notion of a > privilege that superusers might not have was pretty bogus to start with. > > rolcatupdate isn't a very good precedent to rely on because it's never > been documented or used to any noticeable extent, so there's no reason > to think that it provides a tested-and-accepted behavior. That seems fine for 9.2, but I am still not in favor of changing the behavior in back branches. This is not such a confusing behavior that we can't document our way out of it. (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order and we can document our way out of that, this is small potatoes by comparison.) --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Noah Misch <noah@leadboat.com> writes: >>> I think we should merge #3 into #2; nothing about the REPLICATION setting >>> justifies a distinct paradigm. >> Yeah, there's much to be said for that. I thought the notion of a >> privilege that superusers might not have was pretty bogus to start with. > That seems fine for 9.2, but I am still not in favor of changing the > behavior in back branches. This is not such a confusing behavior that > we can't document our way out of it. Agreed, changing it in a minor release would be a bad idea. regards, tom lane
On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote: > On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Noah Misch <noah@leadboat.com> writes: > >> Let's look at the behavior of DDL-exposed access constraints for prece= dent. ?We > >> currently have three paradigms for applying access control to superuse= rs: > > > >> 1. Settings that affect superusers and regular users identically. ?The= se include > >> ALTER ROLE ... LOGIN | VALID UNTIL. > > > >> 2. Rights that superusers possess implicitly and irrevocably; the actu= al setting > >> recorded in pg_authid or elsewhere has no effect. ?These include GRANT= ... ON > >> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. > > > >> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREAT= E ROLE > >> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. > > > >> I think we should merge #3 into #2; nothing about the REPLICATION sett= ing > >> justifies a distinct paradigm. > > > > Yeah, there's much to be said for that. ?I thought the notion of a > > privilege that superusers might not have was pretty bogus to start with. > That seems fine for 9.2, but I am still not in favor of changing the > behavior in back branches. This is not such a confusing behavior that > we can't document our way out of it. >=20 > (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order > and we can document our way out of that, this is small potatoes by > comparison.) Quite so. Let's do it that way.
On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote: > On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote: > > On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > Noah Misch <noah@leadboat.com> writes: > > >> Let's look at the behavior of DDL-exposed access constraints for precedent. ?We > > >> currently have three paradigms for applying access control to superusers: > > > > > >> 1. Settings that affect superusers and regular users identically. ?These include > > >> ALTER ROLE ... LOGIN | VALID UNTIL. > > > > > >> 2. Rights that superusers possess implicitly and irrevocably; the actual setting > > >> recorded in pg_authid or elsewhere has no effect. ?These include GRANT ... ON > > >> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. > > > > > >> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE > > >> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. > > > > > >> I think we should merge #3 into #2; nothing about the REPLICATION setting > > >> justifies a distinct paradigm. > > > > > > Yeah, there's much to be said for that. ?I thought the notion of a > > > privilege that superusers might not have was pretty bogus to start with. > > > That seems fine for 9.2, but I am still not in favor of changing the > > behavior in back branches. This is not such a confusing behavior that > > we can't document our way out of it. > > > > (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order > > and we can document our way out of that, this is small potatoes by > > comparison.) > > Quite so. Let's do it that way. Patch attached.
Attachment
Re: Re: BUG #6264: Superuser does not have inherent Replication permission
From
Heikki Linnakangas
Date:
On 02.01.2012 21:46, Noah Misch wrote: > On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote: >> On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote: >>> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>>> Noah Misch<noah@leadboat.com> writes: >>>>> Let's look at the behavior of DDL-exposed access constraints for precedent. ?We >>>>> currently have three paradigms for applying access control to superusers: >>>> >>>>> 1. Settings that affect superusers and regular users identically. ?These include >>>>> ALTER ROLE ... LOGIN | VALID UNTIL. >>>> >>>>> 2. Rights that superusers possess implicitly and irrevocably; the actual setting >>>>> recorded in pg_authid or elsewhere has no effect. ?These include GRANT ... ON >>>>> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. >>>> >>>>> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE >>>>> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. >>>> >>>>> I think we should merge #3 into #2; nothing about the REPLICATION setting >>>>> justifies a distinct paradigm. >>>> >>>> Yeah, there's much to be said for that. ?I thought the notion of a >>>> privilege that superusers might not have was pretty bogus to start with. >> >>> That seems fine for 9.2, but I am still not in favor of changing the >>> behavior in back branches. This is not such a confusing behavior that >>> we can't document our way out of it. >>> >>> (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order >>> and we can document our way out of that, this is small potatoes by >>> comparison.) >> >> Quite so. Let's do it that way. > > Patch attached. Thanks, committed to master. Was there something that still needed to be done for the 9.1 docs? I'm not sure what the conclusion on that was in the discussions back in October. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Sat, Jan 14, 2012 at 06:34:25PM +0200, Heikki Linnakangas wrote: > On 02.01.2012 21:46, Noah Misch wrote: >> On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote: >>> On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote: >>>> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>>>> Noah Misch<noah@leadboat.com> writes: >>>>>> Let's look at the behavior of DDL-exposed access constraints for precedent. ?We >>>>>> currently have three paradigms for applying access control to superusers: >>>>> >>>>>> 1. Settings that affect superusers and regular users identically. ?These include >>>>>> ALTER ROLE ... LOGIN | VALID UNTIL. >>>>> >>>>>> 2. Rights that superusers possess implicitly and irrevocably; the actual setting >>>>>> recorded in pg_authid or elsewhere has no effect. ?These include GRANT ... ON >>>>>> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. >>>>> >>>>>> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE >>>>>> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. >>>>> >>>>>> I think we should merge #3 into #2; nothing about the REPLICATION setting >>>>>> justifies a distinct paradigm. >>>>> >>>>> Yeah, there's much to be said for that. ?I thought the notion of a >>>>> privilege that superusers might not have was pretty bogus to start with. >>> >>>> That seems fine for 9.2, but I am still not in favor of changing the >>>> behavior in back branches. This is not such a confusing behavior that >>>> we can't document our way out of it. >>>> >>>> (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order >>>> and we can document our way out of that, this is small potatoes by >>>> comparison.) >>> >>> Quite so. Let's do it that way. >> >> Patch attached. > > Thanks, committed to master. Thanks. > Was there something that still needed to be done for the 9.1 docs? I'm > not sure what the conclusion on that was in the discussions back in > October. Not that I noted. The former docs describe the 9.1 behavior thoroughly.