Thread: Upcoming re-releases

The core committee has agreed that it's about time for a new set of
update releases (8.1.3, 8.0.7, etc).  Barring surprises, we'll wrap
Sunday evening with expectation of general announcement Tuesday.
Any pending patches out there for the back branches?
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> The core committee has agreed that it's about time for a new set of
> update releases (8.1.3, 8.0.7, etc).  Barring surprises, we'll wrap
> Sunday evening with expectation of general announcement Tuesday.
> Any pending patches out there for the back branches?

I'd really like to see the multiple DB connections with different
Kerberos credentials go in to 8.1.3.  It solved the problem we were
having authenticating to PostgreSQL using Kerberos from Apache.  We were
also able to get phppgadmin to use Kerberos authentication with this
patch (which is very nice).  That patch also went into the 8.1.2-2
release of the Debian packages (along with the pg_restore patch which
was already committed to CVS).  Havn't heard of any problems with it so
far, though 8.1.2-2 only hit the Debian mirrors yesterday.
Thanks!
    Stephen

Hi,

On Wed, 2006-02-08 at 11:28 -0500, Stephen Frost wrote:

> I'd really like to see the multiple DB connections with different
> Kerberos credentials go in to 8.1.3.  It solved the problem we were
> having authenticating to PostgreSQL using Kerberos from Apache.  We were
> also able to get phppgadmin to use Kerberos authentication with this
> patch (which is very nice).  That patch also went into the 8.1.2-2
> release of the Debian packages 

[OT]
So Debian has a patch that is not in 8.1.2? I can't believe that they
are doing that -- personally I'm against to add any patch into binaries
that is not in the core.
[/OT]

Regards,
-- 
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

* Devrim GUNDUZ (devrim@commandprompt.com) wrote:
> On Wed, 2006-02-08 at 11:28 -0500, Stephen Frost wrote:
> > I'd really like to see the multiple DB connections with different
> > Kerberos credentials go in to 8.1.3.  It solved the problem we were
> > having authenticating to PostgreSQL using Kerberos from Apache.  We were
> > also able to get phppgadmin to use Kerberos authentication with this
> > patch (which is very nice).  That patch also went into the 8.1.2-2
> > release of the Debian packages
>
> [OT]
> So Debian has a patch that is not in 8.1.2? I can't believe that they
> are doing that -- personally I'm against to add any patch into binaries
> that is not in the core.
> [/OT]

Guess you don't use Debian much.
Thanks,
    Stephen

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Any pending patches out there for the back branches?

> I'd really like to see the multiple DB connections with different
> Kerberos credentials go in to 8.1.3.

That's a new feature, not a bug fix.  I'd be against back-patching it
even if it had been in HEAD long enough to get some meaningful amount
of testing ... and since it's not even in HEAD yet ...
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> Any pending patches out there for the back branches?
>
> > I'd really like to see the multiple DB connections with different
> > Kerberos credentials go in to 8.1.3.
>
> That's a new feature, not a bug fix.  I'd be against back-patching it
> even if it had been in HEAD long enough to get some meaningful amount
> of testing ... and since it's not even in HEAD yet ...

It's a bug.  PostgreSQL properly supports using different authentication
credentials across seperate pg_connect()'s for all of the other
authentication types.  The only reason it doesn't for Kerberos is because
of improper use of static variables which aren't reset between the
authentication requests.  The patch fixes this and cleans up the
static variable handling.
Thanks,
    Stephen

* Devrim GUNDUZ (devrim@commandprompt.com) wrote:
> [OT]
> So Debian has a patch that is not in 8.1.2? I can't believe that they
> are doing that -- personally I'm against to add any patch into binaries
> that is not in the core.
> [/OT]

And it's days like these that make me happy to be running Debian.  My
thanks go to Martin for his excellent work.
Enjoy,
    Stephen

> The core committee has agreed that it's about time for a new
> set of update releases (8.1.3, 8.0.7, etc).  Barring
> surprises, we'll wrap Sunday evening with expectation of
> general announcement Tuesday.
> Any pending patches out there for the back branches?

I'd like to see the bugfix part of
http://archives.postgresql.org/pgsql-patches/2006-01/msg00172.php
(postmster_win32_admincheck.patch) if possible.
It's a bugfix, and it helps even without the rest of the patch - for
third party tools.

//Magnus

>[OT]
>So Debian has a patch that is not in 8.1.2? I can't believe that they
>are doing that -- personally I'm against to add any patch into binaries
>that is not in the core.
>[/OT]
>
>  
>
This is not a Debian thing. Lots of distributions do it. I wouldn't be 
surprised
if RedHat did it as well.

Joshua D. Drake


>Regards,
>  
>

On Wed, 8 Feb 2006, Tom Lane wrote:

> The core committee has agreed that it's about time for a new set of
> update releases (8.1.3, 8.0.7, etc).  Barring surprises, we'll wrap
> Sunday evening with expectation of general announcement Tuesday.
> Any pending patches out there for the back branches?
>

I still think this should be applied to back branches.  The patches queue 
is really quite a bit behind.

http://archives.postgresql.org/pgsql-hackers/2006-01/msg00175.php

Kris Jurka

* Joshua D. Drake (jd@commandprompt.com) wrote:
>
> >[OT]
> >So Debian has a patch that is not in 8.1.2? I can't believe that they
> >are doing that -- personally I'm against to add any patch into binaries
> >that is not in the core.
> >[/OT]
> >
> This is not a Debian thing. Lots of distributions do it. I wouldn't be
> surprised
> if RedHat did it as well.

I'm not sure they do but they're not really a fair comparison as they
have a somewhat privileged position due to Tom (not that I'm
complaining, honestly I think it's wonderful that RH has an apparently
dedicated person for Postgres and it's outstanding that it's someone as
intelligent and knowledgable as Tom).  It's certainly not uncommon for
distributions in general to patch programs which make them not-quite
pure upstream.  Then again, just a recompile can break things too so
it's not like pristine source is always an option.  It's also true, as
has been pointed out before, that Debian uses --enable-integer-datetimes
(or whatever the flag is) which isn't enabled by default.  For the vast
majority of Debian users this is correct and better than the default but
it does mean that a PostgreSQL default-options compile will generate a
postmaster that can't work with Debian data files.  Then again, if you
omit --enable-krb5 and the Debian package doesn't then if you move to a
default-compiled version you might not be able to authenticate to your
database anymore either.
Thanks,
    Stephen

On Wed, Feb 08, 2006 at 06:36:10PM +0200, Devrim GUNDUZ wrote:
> On Wed, 2006-02-08 at 11:28 -0500, Stephen Frost wrote:
>
> > I'd really like to see the multiple DB connections with different
> > Kerberos credentials go in to 8.1.3.  It solved the problem we were
> > having authenticating to PostgreSQL using Kerberos from Apache.  We were
> > also able to get phppgadmin to use Kerberos authentication with this
> > patch (which is very nice).  That patch also went into the 8.1.2-2
> > release of the Debian packages
>
> [OT]
> So Debian has a patch that is not in 8.1.2? I can't believe that they
> are doing that -- personally I'm against to add any patch into binaries
> that is not in the core.
> [/OT]

Debian had the patch to enable ident over unix domain sockets well
before core did. So long that I didn't even realise it was a patch
until I compiled my own version. The patch had been submitted upstream
but fell between the cracks. As a Debian user it something I like.

The changelog entry says:
  * Add debian/patches/12-krb5-multiusers.patch:    - Fix krb5 credential handling in libpq for multiple connections
with     different users: Don't keep credentials in global variables, but pass      them around in a new krb5_info
struct.   - Patch from Stephen Frost, proposed to be adopted upstream. 

I consider it a form of preventative bug fixing. Somebody on Debian is
bound to complain about it sooner or later, so may as well fix it now.
There is a group who likes having kerberos working properly...

I imagine if a similar bug affected SSL connections, people would be
jumping up and down to have it fixed.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

>> [OT]
>> So Debian has a patch that is not in 8.1.2? I can't believe that they
>> are doing that -- personally I'm against to add any patch into binaries
>> that is not in the core.
>> [/OT]
> 
> And it's days like these that make me happy to be running Debian.  My
> thanks go to Martin for his excellent work.

Heh don't log into #postgresql then - we have all pretty much been 
convinced after years of newbie support that Debian is the son of the 
devil when it comes to PostgreSQL :)

Chris

Martijn van Oosterhout <kleptog@svana.org> writes:
> On Wed, Feb 08, 2006 at 06:36:10PM +0200, Devrim GUNDUZ wrote:
>> So Debian has a patch that is not in 8.1.2? I can't believe that they
>> are doing that -- personally I'm against to add any patch into binaries
>> that is not in the core.

> I consider it a form of preventative bug fixing.

As against which, you have to consider the probability that the Debian
patch breaks something.  With a maintainer who is not one of the main PG
developers accepting patches that haven't yet been reviewed (much less
beta-tested) by the community, that risk seems far from negligible.

(Now Red Hat certainly also puts in patches that aren't yet released
upstream, but we try to avoid getting ahead of upstream patch development.)
        regards, tom lane

Devrim GUNDUZ wrote:
>
> So Debian has a patch that is not in 8.1.2? I can't believe that they
> are doing that -- personally I'm against to add any patch into binaries
> that is not in the core.


I think the other important thing to consider is that this patch went 
into debian's unstable branch, not stable.

Kris Jurka

* Christopher Kings-Lynne (chriskl@familyhealth.com.au) wrote:
> >>[OT]
> >>So Debian has a patch that is not in 8.1.2? I can't believe that they
> >>are doing that -- personally I'm against to add any patch into binaries
> >>that is not in the core.
> >>[/OT]
> >
> >And it's days like these that make me happy to be running Debian.  My
> >thanks go to Martin for his excellent work.
>
> Heh don't log into #postgresql then - we have all pretty much been
> convinced after years of newbie support that Debian is the son of the
> devil when it comes to PostgreSQL :)

Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it.
Sorry that Debian/stable releases havn't been coming out as frequently
as they really should have been.  We're working on that, honest!
Thanks,
    Stephen

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > On Wed, Feb 08, 2006 at 06:36:10PM +0200, Devrim GUNDUZ wrote:
> >> So Debian has a patch that is not in 8.1.2? I can't believe that they
> >> are doing that -- personally I'm against to add any patch into binaries
> >> that is not in the core.
>
> > I consider it a form of preventative bug fixing.
>
> As against which, you have to consider the probability that the Debian
> patch breaks something.  With a maintainer who is not one of the main PG
> developers accepting patches that haven't yet been reviewed (much less
> beta-tested) by the community, that risk seems far from negligible.

While I appriciate the core developer's expertise I don't think lack of
being a core member alone makes Martin's critique of the patch somehow
less valuable.  I've also posted the patch to both -hackers and -patches
and I'd love for the community to review it.

And, to be fair, it's going into Debian/unstable and won't be in a
stable release without further testing by the Debian/unstable users
and Debian/testing users (once it propagates there).  Unless there are
serious problems with it though I expect it to be in the next stable
Debian release (currently slated for the fall, iirc).  It wouldn't go
into an update to the current Debian/stable as it's not a security fix.

I'm still very much of the opinion it's a bug and it's not terribly
complicated of a fix when you look at it.  The patch looks bigger than
the actual change really is because of the structure references.  Those
pieces aren't actually changed beyond referencing the structure variable
instead of the static variable though.

> (Now Red Hat certainly also puts in patches that aren't yet released
> upstream, but we try to avoid getting ahead of upstream patch development.)

Debian in general doesn't like to differ much from upstream and so it
would certainly be nice to have the patch accepted into *some* point
release which could be included in the next stable Debian release.  It
seems unlikely 8.2 will be out with enough time for it go through
Debian's testing before the next stable Debian release.
Thanks,
    Stephen

Kris Jurka wrote:
> 
> 
> On Wed, 8 Feb 2006, Tom Lane wrote:
> 
> > The core committee has agreed that it's about time for a new set of
> > update releases (8.1.3, 8.0.7, etc).  Barring surprises, we'll wrap
> > Sunday evening with expectation of general announcement Tuesday.
> > Any pending patches out there for the back branches?
> >
> 
> I still think this should be applied to back branches.  The patches queue 
> is really quite a bit behind.
> 
> http://archives.postgresql.org/pgsql-hackers/2006-01/msg00175.php

Yes, it is, no question.  I am working on the INET + INT patch now.

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

Devrim GUNDUZ <devrim@commandprompt.com> wrote:
> Hi,
>
> On Wed, 2006-02-08 at 11:28 -0500, Stephen Frost wrote:
>
>> I'd really like to see the multiple DB connections with different
>> Kerberos credentials go in to 8.1.3.  It solved the problem we were
>> having authenticating to PostgreSQL using Kerberos from Apache.  We were
>> also able to get phppgadmin to use Kerberos authentication with this
>> patch (which is very nice).  That patch also went into the 8.1.2-2
>> release of the Debian packages 
>
> [OT]
> So Debian has a patch that is not in 8.1.2? I can't believe that they
> are doing that -- personally I'm against to add any patch into binaries
> that is not in the core.
> [/OT]


You haven't been looking too closely at the way some distributions are
building their packages then. At least two of the distributions I use
regularly (Gentoo and Debian) have the habit of adding a load of patches
during package build. And not all of those go back to the upstream, to
put it mildly ...

Regards,      Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls andlooks like work."
         -- Thomas A. Edison
 

Alexander Schreiber wrote:

>At least two of the distributions I use
>regularly (Gentoo and Debian) have the habit of adding a load of patches
>during package build. And not all of those go back to the upstream, to
>put it mildly ...
>
>  
>


And they are not always sensible. A while back the Gentoo packagers 
decided to "improve" the messages from initdb - the patch they applied 
was completely erroneous, and I believe they have now fixed it.

I tend to be suspicious of distro applied patches. (I do like the change 
to use log rotation that recent Rh/Fedora packages have made.)

cheers

andrew

Stephen Frost wrote:

> Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it.
> Sorry that Debian/stable releases havn't been coming out as frequently
> as they really should have been.  We're working on that, honest!

The only thing that I hate is that libpq defaults to searching the
local socket in /var/postgresql/ or thereabouts.  It really drives me
crazy and I've banned the libpq packages from my system.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

* Alvaro Herrera (alvherre@commandprompt.com) wrote:
> Stephen Frost wrote:
> > Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it.
> > Sorry that Debian/stable releases havn't been coming out as frequently
> > as they really should have been.  We're working on that, honest!
>
> The only thing that I hate is that libpq defaults to searching the
> local socket in /var/postgresql/ or thereabouts.  It really drives me
> crazy and I've banned the libpq packages from my system.

Perhaps /var/run/postgresql/?  Where do you think it should go...?
Thanks,
    Stephen

Stephen Frost wrote:
> * Alvaro Herrera (alvherre@commandprompt.com) wrote:
> > Stephen Frost wrote:
> > > Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it.
> > > Sorry that Debian/stable releases havn't been coming out as frequently
> > > as they really should have been.  We're working on that, honest!
> > 
> > The only thing that I hate is that libpq defaults to searching the
> > local socket in /var/postgresql/ or thereabouts.  It really drives me
> > crazy and I've banned the libpq packages from my system.
> 
> Perhaps /var/run/postgresql/?  Where do you think it should go...?

Where the upstream package puts it, /tmp ...  But yeah, I know about the
Debian Policy.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:

>Stephen Frost wrote:
>  
>
>>* Alvaro Herrera (alvherre@commandprompt.com) wrote:
>>    
>>
>>>The only thing that I hate is that libpq defaults to searching the
>>>local socket in /var/postgresql/ or thereabouts.  It really drives me
>>>crazy and I've banned the libpq packages from my system.
>>>      
>>>
>>Perhaps /var/run/postgresql/?  Where do you think it should go...?
>>    
>>
>
>Where the upstream package puts it, /tmp ...  But yeah, I know about the
>Debian Policy.
>
>  
>
Maybe this should be a configure flag, just like the port number is.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Maybe this should be a configure flag, just like the port number is.

It is ... that isn't the issue, the problem is exactly that Debian
chooses to exercise the option to make their installations different
from everyone else's.
        regards, tom lane

On Thu, Feb 09, 2006 at 03:16:29PM -0500, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Maybe this should be a configure flag, just like the port number is.
>
> It is ... that isn't the issue, the problem is exactly that Debian
> chooses to exercise the option to make their installations different
> from everyone else's.

FWIW, I prefer the Debian location. AFAICS the only rationale for
putting it in /tmp is "because it's always been there". I also agree
with suggestions to move ssh and X11 sockets out of /tmp. /tmp should
be for, well, temporary files...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Martijn van Oosterhout <kleptog@svana.org> writes:
> FWIW, I prefer the Debian location. AFAICS the only rationale for
> putting it in /tmp is "because it's always been there".

Actually, it's "because it's certain to be there and be accessible to
unprivileged users".  If we tried to change to something like
/var/postgresql, then getting that directory made and properly
permissioned would be an additional installation-time stumbling block
in the way of newbies.  That's not an issue for prepackaged builds that
(at some level) require root privs to install, but I don't foresee it
becoming the default for builds from source.  Especially not given the
client/server compatibility problems it'd create.
        regards, tom lane

On 2/9/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Maybe this should be a configure flag, just like the port number is.
>
> It is ... that isn't the issue, the problem is exactly that Debian
> chooses to exercise the option to make their installations different
> from everyone else's.

It is exatly distributor's job to give consistent system.  I would
not like to use a distro that just does './configure;make;make install'
without any overview.

Especially considering that upstream defaults are bad.

OTOH as upstream job is _not_ to care about consistent system
- as it is not possible - then for upstream the backwards compatibility
is the most important thing.  It is likely that PostgreSQL upstream can
move the default only when most distros have already changed to sane
setting.

Oh, and I personally like that self-compiled PostgreSQL defaults to
other locations than system one.  Lessens danger of using experimental
stuff on useful data.

--
marko

* Tom Lane:

> Actually, it's "because it's certain to be there and be accessible to
> unprivileged users".

Isn't this a bit problematic because any local user can impersonate a
PostgreSQL backend which has been shut down?

On Sat, Feb 11, 2006 at 03:04:00PM +0100, Florian Weimer wrote:
> * Tom Lane:
>
> > Actually, it's "because it's certain to be there and be accessible to
> > unprivileged users".
>
> Isn't this a bit problematic because any local user can impersonate a
> PostgreSQL backend which has been shut down?

Well, I guess it's an issue. At least it's not suceptable to the
standard symlink attacks. There is in general no way of knowing if the
server you are connecting to is what you think it is (except via SSL
maybe?).

The good thing is that if you're using md5 auth they can't grab your
password. The bad thing is that the server decides the authentication
protocol :(. Man-in-the-middle attacks would only be feasable for
attacker that have the same UID as the postmaster (deleting the socket
and creating a new one over the top). In those cases there's little you
can do anyway.

Putting the socket in a directory owned by the postgres user does stop
other users impersonating the server. Currently, if two local users
both compile a postgres server, they may end up connecting to
eachothers servers :).

These no real way around this. The only real option would be moving to
a home directory but that would require knowing the username the server
is running under...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Martijn van Oosterhout <kleptog@svana.org> writes:
> These no real way around this. The only real option would be moving to
> a home directory but that would require knowing the username the server
> is running under...

And the problem would still exist, with even less chance of solution,
for TCP connections which are probably the majority of real-world usage.
If you're concerned about this sort of attack I think it has to be
solved in the protocol, not by reliance on socket placement.

I'm not sure whether our current SSL support does a good job of this
--- I think it only tries to check whether the server presents a
valid certificate, not which cert it is.  Possibly Kerberos does more,
but I dunno a thing about that...
        regards, tom lane

> I'm not sure whether our current SSL support does a good job of this
> --- I think it only tries to check whether the server
> presents a valid certificate, not which cert it is.  Possibly
> Kerberos does more, but I dunno a thing about that...

If you stick a root certificate (root.crt in ~/.postgresql) for it to
validate against, it will be validated against that root. I'm not sure
if it validates the common name of the cert though - that would be an
issue if you're using a global CA. If you're using a local enterprise
CA, that's a much smaller issue (because you yourself have total control
over who gets certificates issued by the CA).

The way our Kerberos implementation is done, it does *not* validate the
server, just the client. If you want server verification, you must use a
combination of both Kerberos and SSL.

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:
> If you stick a root certificate (root.crt in ~/.postgresql) for it to
> validate against, it will be validated against that root. I'm not sure
> if it validates the common name of the cert though - that would be an
> issue if you're using a global CA. If you're using a local enterprise
> CA, that's a much smaller issue (because you yourself have total control
> over who gets certificates issued by the CA).

But in either case, it would only be checking that the cert had been
issued by that CA, no?  Unless you set up a CA that only ever issues
certificates to your PG server, someone else with a cert from the CA
could still impersonate.  Or am I mistaken about that?
        regards, tom lane

* Martijn van Oosterhout:

> Well, I guess it's an issue. At least it's not suceptable to the
> standard symlink attacks. There is in general no way of knowing if the
> server you are connecting to is what you think it is (except via SSL
> maybe?).

For local (i.e. UNIX domain socket) connections, there is -- just use
a hard-coded path where each directory is only writable by root or by
the PostgreSQL superuser (/var/run in Debian is not world-writable,
for instance).

> The good thing is that if you're using md5 auth they can't grab your
> password.

The password is probably of little concern if you use UNIX domain
sockets.  But feeding wrong data to the application might trigger
interesting things.

> > If you stick a root certificate (root.crt in ~/.postgresql)
> for it to
> > validate against, it will be validated against that root.
> I'm not sure
> > if it validates the common name of the cert though - that
> would be an
> > issue if you're using a global CA. If you're using a local
> enterprise
> > CA, that's a much smaller issue (because you yourself have total
> > control over who gets certificates issued by the CA).
>
> But in either case, it would only be checking that the cert
> had been issued by that CA, no?  Unless you set up a CA that
> only ever issues certificates to your PG server, someone else
> with a cert from the CA could still impersonate.  Or am I
> mistaken about that?

Correct. But if you run your own enterprise CA, that's exactly the kind
of thing you can make sure - that nobody else has a certificate from
that CA.

But no, it wouldn't be bad if there was a way to specify exactly which
cert is used. Or at least validate the common name of it agains the
hostname of the server.


//Magnus

* Magnus Hagander:

> But no, it wouldn't be bad if there was a way to specify exactly which
> cert is used. Or at least validate the common name of it agains the
> hostname of the server.

SSH-like "leap of faith" authentication would be even better.  Store
the certificate on the first connection (together with the domain
name), and refuse subsequent connections if the certificate changes.

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > These no real way around this. The only real option would be moving to
> > a home directory but that would require knowing the username the server
> > is running under...
>
> And the problem would still exist, with even less chance of solution,
> for TCP connections which are probably the majority of real-world usage.
> If you're concerned about this sort of attack I think it has to be
> solved in the protocol, not by reliance on socket placement.
>
> I'm not sure whether our current SSL support does a good job of this
> --- I think it only tries to check whether the server presents a
> valid certificate, not which cert it is.  Possibly Kerberos does more,
> but I dunno a thing about that...

With AP_OPTS_MUTUAL_REQUIRED (which we and most other Kerberos
client/server setups use), the user and the server authenticate to each
other.  The server has to prove it has access to the same key the KDC
has on file for the server, and the client has to do the same.  We
really should support the various options for SSL checking.  Options to
define trusted CAs, checking CN against what the IP address of the
server resolves to, mapping of DN to username (perhaps regexp based),
explicitly certificate -> username mapping, etc...

Of course, it'd be nice to get SASL support and move to GSSAPI instead
of the Kerberos API... :)
Thanks,
    Stephen

* Magnus Hagander (mha@sollentuna.net) wrote:
> The way our Kerberos implementation is done, it does *not* validate the
> server, just the client. If you want server verification, you must use a
> combination of both Kerberos and SSL.

Eh?  We use mutual authentication in Kerberos...
Stephen

> > The way our Kerberos implementation is done, it does *not* validate
> > the server, just the client. If you want server
> verification, you must
> > use a combination of both Kerberos and SSL.
>
> Eh?  We use mutual authentication in Kerberos...

We do? That's good then :-) I was told by someone that we don't. Never
really checked into it, since all my installations already use SSL for
that. So, I'll retract my comment ;)

//Magnus

* Magnus Hagander (mha@sollentuna.net) wrote:
> > > The way our Kerberos implementation is done, it does *not* validate
> > > the server, just the client. If you want server
> > verification, you must
> > > use a combination of both Kerberos and SSL.
> >
> > Eh?  We use mutual authentication in Kerberos...
>
> We do? That's good then :-) I was told by someone that we don't. Never
> really checked into it, since all my installations already use SSL for
> that. So, I'll retract my comment ;)

We pass in 'MUTUAL_REQUIRED' to krb5_sendauth and check the return value
of it correctly...  I'd be really curious why 'someone' felt we weren't
doing mutual authentication...  I don't see anything obvious..
Thanks,
    Stephen