Using Kerberos5 in 3.3p1

[Simon Wilkinson]

On 27 Jun 2002, Dag-Erling Smorgrav wrote:

> Hans Insulander <hin at stacken.kth.se> writes:
> > What needs to be done, afaik, is to receive the kerberos auth data in the
> > unprivileged client process, marshal it and send over to the monitor process.
> > The monitor should validate the information and say "ok" or "not ok" back to
> > the client. I have very little clues as how to do that.
>
> I can work on this tomorrow provided someone can help me with the
> Kerberos aspect of things.

I've just completed adding privsep support to my GSSAPI patches. They're
being tested and reviewed at present, I hope to be able to release them
tomorrow.

Based on my experience with these, and a quick review of the krb5 code,
can I offer the following:

You need to decide upon which process the Kerberos context lives in. I
think, due to the libraries reliance on configuration (and stash) files
in /etc/ this is going to have to be the priviledged process. So, most
of the code in auth_krb5 needs to be called through the privsep monitor.

auth_con_setaddrs_from_fd() will cause problems, as I don't think the
priviledged process has the file descriptor of the connection. You can
probably get around this by working out the necessary information (local
addr, remote addr) and passing this through the monitor to a different
variant of the setaddrs function.

Similarly, auth_krb5_tgt probably needs to be a stub, with most of the
work being done in the priviledged process. I'm not sure if you want to
still create the credentials cache here, or defer it to a later stage
(by copying the delegated credentials to a memory cache)

Apart from that, and providing you're happy with the implications of
copying chunks of network data straight from the child to the parent,
it looks fairly straight-forward.

If no-one else gets to this before next week, I could possibly have a more
in-depth look then.

Cheers,

Simon.