Re: Open 7.3 items - Mailing list pgsql-hackers

I would like to address this email.  

Lamar is mentioning that it is unfair to remove a feature without
warning.

Let me give a little history.  The secondary password file was created
at a time when we didn't encrypt with random salt over the wire, and we
had people who wanted to share their /etc/passwd file with PostgreSQL.

Later, people wanted to use the secondary password file for just
usernames, so you could list usernames in the file and limit db access
by user.  This is the current usage for 99% of secondary password users.
This capability is better served in 7.3 with the new USER column in
pg_shadow and the ability to specify filenames or groups in that file. 
Keeping the secondary password file to specify a user list while a new
USER column exists in 7.3 is just confusing to administrators.  Our
pg_hba.conf system is pretty complex, so anything we can do to simplify
helps.

Now, on to Marc's case, where he does use the file for usernames _and_
passwords.  However, he is using it only so he can have more than one
person with the same username and restrict access based on the password
in the secondary password file.  While this does work, my submitted
patch makes this much easier and cleaner.

Marc had mentioned that this should be an initdb flag.  However, our
standard procedure is to put stuff in initdb only when it can't be
changed after initdb.  While strange, this feature can be
enabled-disabled after initdb.  A quick update of pg_shadow can change
usernames and you can go in and out of this mode.

Someone talked about pushing this capability into a separate pg_shadow
column, and making CREATE/ALTER user and createuser aware of this. 
While this can be done, and it sort of becomes user schemas, there isn't
enough people wanting this to add complexity to those commands.  A GUC
flag will meet most peoples needs at this point.

Some mentioned using user@dbname, though the idea of sorting made
several recant their votes.

So, based on the voting, I think dbname.username is an agreed-upon
feature addition for 7.3.  I will work on a final patch with
documentation and post it to the patches list for more comment.

---------------------------------------------------------------------------

Lamar Owen wrote:
> On Tuesday 06 August 2002 09:24 pm, Marc G. Fournier wrote:
> > On Tue, 6 Aug 2002, Bruce Momjian wrote:
> > > It had such limited usefulness ('password' only, only crypted-hashed
> > > passwords in the file) that it doesn't make much sense to resurect it.
> 
> > It had limited usefulness to you ... but how many sites out there are
> > going to break when they try to upgraded without it there?  I do agree
> > that it needs to improved / replaced, but without a suitable replacement
> > in place, the old should be resurrected until such a suitable one is in
> > place ...
> 
> While it appears I'll be outvoted on this issue, and even though I agree that 
> the existing functionality is broken, and even though I am not using the 
> functionality, I am reminded of the overall policy that we have historically 
> had about removing even broken features.  Fair Warning must be given. If that 
> policy is going to be changed, then it needs to be applied with equal vigor 
> to all affected cases.
> 
> Even if Marc is the only one using this feature, we should follow established 
> policy -- that is, after all, what policy is for.  To me it seems it is being 
> yanked gratuitously without fair warning.  If every question is answered on a 
> case-by-case basis like this, we will descend to anarchy, I'm afraid.  And, 
> Bruce, I even agree with your reasons -- I just disagree with the method.
> 
> Is it going to cause a major problem for it to remain one release cycle while 
> someone works on a suitable replacement, with the warning in the release 
> notes that while this feature is there for backwards compatibility that it 
> will be yanked at the next release?  And I'm not talking about a minor 
> problem like 'more people will start using it' -- I'm talking 'if it stays we 
> will be in danger of massive data corruption or exposure' -- of course, 
> documenting that there is a degree of exposure of data if not set up in an 
> exacting method, as Marc seems to have done.
> 
> Some may say Marc has fair warning now -- but does anyone know for sure that 
> NO ONE ELSE in the whole world isn't using this feature?  Marc is more in the 
> know than most, granted -- but if he found this use for the feature others 
> may have as well that we don't even know about.
> 
> But if the feature is not going to remain it needs to be prominently 
> documented as being removed in the release notes.

--  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,
Pennsylvania19073