directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <enriqu...@gmail.com>
Subject Re: [ApacheDS] SASL Branch
Date Wed, 09 May 2007 22:15:54 GMT
On 5/9/07, Alex Karasulu <akarasulu@apache.org> wrote:
> On 5/9/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> > ...
> > Test log would be helpful but I suspect it is the Kerberos port
> > binding issue I mentioned, namely that the JDK Kerberos client doesn't
> > allow you to specify port in code, so it will default to the Kerberos
> > port, 88, which requires root to bind.
>
> That's going to present a problem for us.  We cannot perform this test if it
> has to run as root:
> those checking out the code to build the server and test the server are not
> going to want to
> have to run as root to make the tests pass.  You can imagine the problems
> this will cause us.
>  Is there no other way?  I'd hate to disable the test overall since it's
> great to have if we wind
> up breaking the SASL mechanism with changes.

1)  I looked into the JDK to see if there was config for the Kerberos
port, but couldn't find one.  There could still be some way to set it,
in code.

2)  I thought about passing byte[] captures into the handler to test,
but the issue comes up that validity periods are tested and we run
into the same issue of not being able to easily extend any validity
periods.

3)  We can still run the non-GSSAPI SASL tests, which do test most of
the SASL Bind code.

4)  As you noted, the best option is a Kerberos client with some
visibility into its inner workings.  I just started in on a client for
key export.  I can look at working on a basic Kerberos client at the
same time.  Perhaps at least one with the minimum capability to
resolve this test.  This won't be a 1-weekend project, though.

> BTW I just ran this test again not as root tho and it passed this time but
> produced
> the following stack trace on the command line.  I guess you're dumping the
> trace
> in your test case out to stderr.  We might not want to do that.

We definitely don't want to do that.  I missed cleaning that test case
of stacktraces and System.out/err.  I committed the changes.

Enrique

Mime
View raw message