From owner-freebsd-current@FreeBSD.ORG Fri Jun 12 19:21:31 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 457BE10656B2 for ; Fri, 12 Jun 2009 19:21:31 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 05EAE8FC0A for ; Fri, 12 Jun 2009 19:21:30 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id n5CJLTxF076813; Fri, 12 Jun 2009 13:21:30 -0600 (MDT) Message-ID: <4A32AAB4.8010602@FreeBSD.org> Date: Fri, 12 Jun 2009 13:21:24 -0600 From: Jamie Gritton User-Agent: Thunderbird 2.0.0.19 (X11/20090109) MIME-Version: 1.0 To: Rick Macklem References: <20090611170448.M22887@maildrop.int.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9462/Fri Jun 12 12:07:06 2009 on gritton.org X-Virus-Status: Clean Cc: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org Subject: Re: kgssapi won't build, I need prison help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 19:21:31 -0000 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 > @@ -305,6 +305,7 @@ > 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 > @@ -3221,6 +3221,22 @@ > } > > /* > + * 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