kgssapi won't build, I need prison help
Jamie Gritton
jamie at FreeBSD.org
Fri Jun 12 19:21:31 UTC 2009
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
More information about the freebsd-current
mailing list