Re: kgssapi won't build, I need prison help

Rick Macklem wrote:
 > On Thu, 11 Jun 2009, Bjoern A. Zeeb wrote:
 >> On Thu, 11 Jun 2009, Rick Macklem wrote:
 >>
 >> Hi,
 >>
 >>> No, I know how to get thrown in prison:-), but I don't know what
 >>> "prison" should be used by the rpcsec_gss server (options KGSSAPI).
 >>>
 >>> options KGSSAPI doesn't build right now. One place is just in need
 >>> of jail.h, but in another, it still uses "hostid". I assume this
 >>> should become pr_hostid, but for what "prison"? (would prison0.pr_host
 >>> be ok?)
 >>
 >> 1) note pr_hostid is unsinged long, ci_hostid is unit32_t.
 >>
 >> 2) I do not know what that code does but ideally it should be from the
 >>   same context as being called which might be hard in this case.
 >>
 >>   For svc_rpc_gss_find_client you may want to move the check into the
 >>   foreach loop as an addition criteria; client seems to know the
 >>   context it runs in (cred-> ...)
 >>
 >>   For svc_rpc_gss_create_client() I would say you'll have to pass in
 >>   the correct context.
 >>
 > How about adding the following patch and then the svc_rpcsec_gss.c code
 > can call getcredhostid(curthread->td_ucred)?
 >
 > Note that this stuff is used by the nfsserver, so the threads are all
 > children of the nfsd daemon. (The credentials in that code are generated
 > by the gssd from a Kerberos principal name like "rick" and consist of a
 > uid + gid list for a remote user.)
 >
 > I have no idea if running the nfsd inside a prison makes any sense. If
 > not, maybe it could just be getcredhostid(NULL) instead?
 >
 > What do you think? rick
 > --- possible patch for jail ---
 > --- sys/jail.h.sav    2009-06-12 13:42:35.000000000 -0400
 > +++ sys/jail.h    2009-06-12 13:43:09.000000000 -0400
 > _at__at_ -305,6 +305,7 _at__at_
 >  struct statfs;
 >  int jailed(struct ucred *cred);
 >  void getcredhostname(struct ucred *cred, char *, size_t);
 > +unsigned long getcredhostid(struct ucred *cred);
 >  int prison_allow(struct ucred *, unsigned);
 >  int prison_check(struct ucred *cred1, struct ucred *cred2);
 >  int prison_canseemount(struct ucred *cred, struct mount *mp);
 > --- kern/kern_jail.c.sav    2009-06-12 13:39:46.000000000 -0400
 > +++ kern/kern_jail.c    2009-06-12 13:41:58.000000000 -0400
 > _at__at_ -3221,6 +3221,22 _at__at_
 >  }
 >
 >  /*
 > + * Ditto for the hostid.
 > + */
 > +unsigned long
 > +getcredhostid(struct ucred *cred)
 > +{
 > +    struct prison *pr;
 > +    unsigned long ret_hostid;
 > +
 > +    pr = (cred != NULL) ? cred->cr_prison : &prison0;
 > +    mtx_lock(&pr->pr_mtx);
 > +    ret_hostid = pr->pr_hostid;
 > +    mtx_unlock(&pr->pr_mtx);
 > +    return (ret_hostid);
 > +}
 > +
 > +/*
 >   * Determine whether the subject represented by cred can "see"
 >   * status of a mount point.
 >   * Returns: 0 for permitted, ENOENT otherwise.

No, nfsd in a proson doesn't make any sense (at least to me).  The NFS
server itself created its own unjailed cred, so I would expect the
auxillary stuff needs to be unjailed as well.  You still may want to
use the cred's jail though - it seems there may be a chance of
permission escalation otherwise.

- Jamie