[torquedev] how's the gssapi branch acting?

Sergio Gelato Sergio.Gelato at astro.su.se
Tue Jul 17 14:35:24 MDT 2007

* Garrick Staples [2007-07-16 16:20:08 -0700]:
> On Mon, Jul 16, 2007 at 05:03:53PM -0400, Adam Steenwyk alleged:
> > Hi Garrick,
> > 
> > Thanks for your interest in how things are going.  We've been working on
> > replacing an aging PBS Pro license with the gssapi branch at the moment and
> > are still in the testing stage.  While working to get torque running on a
> > RHEL4 master and RHEL5 client, I noticed that the path to kdestroy was
> > hard-coded into src/server/job_func.c.  On our system this lead to old
> > credentials not being destroyed in /var/spool/torque/server_priv/creds.  I
> > have replaced this hard coded path with an automatically configured #define
> > which is generated using autoconf.
> Agreed and I've applied your patch but used AC_PROG_PATHS in
> configure.ac.

There are a few more instances of hard-coded paths (kinit and aklog come
to mind), and other minor clean-ups of this kind are needed here and
there. I haven't rushed to fix these details since I feel that the first
priority should be to make all required changes to the wire-level protocol. 
Once the latter is stable, I see no objection to making a GSSAPI-capable 

Ideally I'd like to GSSize the rpp protocol (along the same lines as for
the TCP DIS code, to provide integrity and optional confidentiality
protection) and allow all communication between server, scheduler and
MOMs to use GSSAPI if a site so wishes.

I'm also regretting that I didn't follow the tradition of RFCs 1731,
2222 and 4752 to have the client and server explicitly negotiate the
integrity and confidentiality levels instead of using the maximum
supported by the security context; but this is largely cosmetic and
can be fixed if and when someone later feels the urge to implement
generic SASL (RFC 4222) support.

> > In /src/resmom/start_exec.c I also noticed some strange behavior - two lines
> > of code which seem to rely on one another being executed first - which may
> > be an error.  It seems that to function truly correctly with -werror, the
> > malloc needs to be put somewhere within the getgroups function.  Please see
> > my comment in the patch and correct my poor c if I am totally off base :).
> When getgroups() is called with the first arg of 0, then the list isn't
> modified; so that part is OK.  But further down the list is searched
> before the later calls that actually populate it.  It looks like a bad
> fuzzy patch apply to me.
> This stuff is differs for trunk and it shouldn't.  I'm going to revert
> this to the trunk code.

I believe I pointed out this issue at the end of May.

I hope to go into production with (my own development version of) the 
GSSAPI branch by the end of this summer. This will be rather small-scale, 
though. For now, I'm still on vacation and haven't had a chance to
review your latest merges into the gssapi branch.

More information about the torquedev mailing list