On Thu, Nov 02, 2006 at 01:10:14PM -0800, Henry B. Hotz wrote:
> standard protocols and libraries that support real security: SASL
> and GSSAPI in particular. You may for various reasons decide that

[. . .]

> Part of establishing a secure connection is establishing that the end
> points are the intended ones and there is no Man In the Middle.
> Establishing the end points means the server has identified the user
> within the name space of the security mechanism.

For what it's worth, I heartily support this effort. For most cases,
it probably isn't necessary, but I can think of several applications
for SASL/GSSAPI where something weaker will simply not do; in the
absence of the proposed functionality, I simply wouldn't be able to
use Postgres for those applications.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

All,

> For what it's worth, I heartily support this effort. *For most cases,
> it probably isn't necessary, but I can think of several applications
> for SASL/GSSAPI where something weaker will simply not do; in the
> absence of the proposed functionality, I simply wouldn't be able to
> use Postgres for those applications.

I'll also add that there are an increasing number of apps and
authentication environments which use SASL or GSSAPI. Supporting these
means that we are no longer locked out of those companies. I know that
the Solaris folks would prefer us to use GSSAPI.

And if there is some reasonably large number of people using a particular
athentication method, we should support it if someone is offering us the
code. Why would we reject a piece of useful functionality based on a
published standard?

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Josh Berkus <josh@agliodbs.com> writes:
> ... Why would we reject a piece of useful functionality based on a
> published standard?

Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related example, I bet
we'd have rejected the original Kerberos-support patch if we'd known
then what we know now. It's been a constant source of bugs ever since
it went in, and with so few users of the feature, it takes a long time
to find the problems.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> ... Why would we reject a piece of useful functionality based on a
>> published standard?
>
> Well, size and maintainability of the proposed patch are certainly
> factors in any such decision. As a closely related example, I bet
> we'd have rejected the original Kerberos-support patch if we'd known
> then what we know now. It's been a constant source of bugs ever since
> it went in, and with so few users of the feature, it takes a long time
> to find the problems.

To be honest, I have often wondered *why* we support kerberos outside of
the uber l33t geek factor. I have not once in a commercial deployment
had a business requirement for the beast. LDAP? Now that is a whole
other issue

Joshua D. Drake


>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> > ... Why would we reject a piece of useful functionality based on a
> > published standard?
>
> Well, size and maintainability of the proposed patch are certainly
> factors in any such decision. As a closely related example, I bet
> we'd have rejected the original Kerberos-support patch if we'd known
> then what we know now. It's been a constant source of bugs ever since
> it went in, and with so few users of the feature, it takes a long time
> to find the problems.

Funny, I really wonder why you feel there's few users of it. I use
kerberos auth on quite a few hosts and I've heard of at least a couple
others on this (not all that frequented) list. Kerberos is really
rather popular, made more so through SSPI and GSSAPI...

Thanks

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFSsGtrzgMPqB3kigRAtHhAJ9C8UEXGpps1CrGc78HJt Gex2FByQCfY2X7
hpOMpY18fUrvwb7G3qIkNHQ=
=QeYT
-----END PGP SIGNATURE-----

On Thu, Nov 02, 2006 at 07:49:01PM -0800, Joshua D. Drake wrote:
> To be honest, I have often wondered *why* we support kerberos outside of
> the uber l33t geek factor. I have not once in a commercial deployment
> had a business requirement for the beast. LDAP? Now that is a whole
> other issue

Isn't NFSv4 a big application that uses Kerberos? I seem to recall that
AFS may have been a large user as well.

The only reason it isn't widely used is because companies are slow to
change. We still use NIS for host names in too many places!

Cheers,
mark

--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
.. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

> >> ... Why would we reject a piece of useful functionality based on a
> >> published standard?
> >
> > Well, size and maintainability of the proposed patch are certainly
> > factors in any such decision. As a closely related example, I bet
> > we'd have rejected the original Kerberos-support patch if
> we'd known
> > then what we know now. It's been a constant source of bugs
> ever since
> > it went in, and with so few users of the feature, it takes
> a long time
> > to find the problems.
>
> To be honest, I have often wondered *why* we support kerberos
> outside of the uber l33t geek factor. I have not once in a
> commercial deployment had a business requirement for the
> beast. LDAP? Now that is a whole other issue

Single sign-on in a Windows/AD environment (I'm talking clients on
windows, servers on linux here - at least in my case). I know several
people who use it, most just don't post here ;-)

Now, it would likely be a lot *easier* to do this with GSSAPI than the
pure kerberos stuff we have now, given that the Windows native APIs
support GSSAPI compatible stuff, but not the stuff we have now.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

> > To be honest, I have often wondered *why* we support
> kerberos outside
> > of the uber l33t geek factor. I have not once in a commercial
> > deployment had a business requirement for the beast. LDAP?
> Now that is
> > a whole other issue
>
> Isn't NFSv4 a big application that uses Kerberos? I seem to
> recall that AFS may have been a large user as well.

AFS definitly used it.

But if you're looking for a "big application" that uses Kerberos,
there's that pesky thing called Windows. Every single Windows machine in
an active directory domain environment is a Kerberos client, and uses
Kerberos for authentication to all network services.

So Kerberos is definitly big. And more and more apps do support GSSAPI
for authentication. Not that many apps support "raw kerberos" as pgsql
does, probably because it does have some compatibility issues and such
things.

//Magnus

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

http://www.postgresql.org/docs/faq

>> To be honest, I have often wondered *why* we support kerberos
>> outside of the uber l33t geek factor. I have not once in a
>> commercial deployment had a business requirement for the
>> beast. LDAP? Now that is a whole other issue
>
> Single sign-on in a Windows/AD environment (I'm talking clients on
> windows, servers on linux here - at least in my case). I know several
> people who use it, most just don't post here ;-)

Wouldn't the LDAP auth in 8.2 resolve that?

>
> Now, it would likely be a lot *easier* to do this with GSSAPI than the
> pure kerberos stuff we have now, given that the Windows native APIs
> support GSSAPI compatible stuff, but not the stuff we have now.

Nod.

Sincerely,

Joshua D. Drake



>
> //Magnus
>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate


---------------------------(end of broadcast)---------------------------
TIP 1: 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

> >> To be honest, I have often wondered *why* we support
> kerberos outside
> >> of the uber l33t geek factor. I have not once in a commercial
> >> deployment had a business requirement for the beast. LDAP?
> Now that
> >> is a whole other issue
> >
> > Single sign-on in a Windows/AD environment (I'm talking clients on
> > windows, servers on linux here - at least in my case). I
> know several
> > people who use it, most just don't post here ;-)
>
> Wouldn't the LDAP auth in 8.2 resolve that?

No. LDAP gives me single credentials, but not single sign-on. I still
have to enter my password every time I connect.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate