Project

General

Profile

Actions

Bug #13329

open

rpcsec & friends need to be zone-aware

Added by Dan McDonald about 1 year ago. Updated 4 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
nfs - NFS server and client
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Expert
Tags:
Gerrit CR:

Description

Inspired by this smartos-live filing: https://github.com/joyent/smartos-live/issues/963, I dove into the source to see why a non-global zone NFS server requires a global zone network/rpc/gss service running.

The answer is summarized in the subject line.

There appear to be four kernel modules we should examine:

1.) kgssapi ===> This module seems to be at least mildly zone-aware. If you look at usr/src/uts/common/gssapi/gssdmod.c you'll see it at least has zone_key_create() and friends. I also am 70% sure this is client code, not server code. I'll note it has the gssd_clnt_stubs.c file, which appears to have entry points called by the below modules. EVERY FUNCTION in that file from what I can tell calls the internal getgssd_handle() which does per-zone lookup, but based on curzone().

2.) rpcsec ===> THIS module is not zone-aware at all. I'm also 70% sure this is the server code. We need to dive into this and make it zone-aware. The init function is in usr/src/uts/common/rpc/sec/secmod.c and it's global-only. :(

3.) rpcsec_gss ===> Same problems as rpcsec. It also launches a single taskq in global-zone context, which is why in kgssapi curzone() is always "global". The init function here is in usr/src/uts/common/rpc/sec_gss/rpcsec_gssmod.c and it's also global-only.

4.) kmech_krb5 ===> This is the Kerberos goodies that GSSAPI in practice uses. I suspect this needs to be rearchitected to reflect any needed changes in rpcsec_gss (since this is a "plugin" to gssapi).

I don't think this is going to be an easy fix, folks. I believe what will need to happen is:

  • rpcsec will need to be a bit more zone aware in general. This module includes the old DES rpcsec, and callouts to rpcsec_gss.
  • The specific bug here requires getting rpcsec_gss as well zone-aware, INCLUDING its plugin architecture.
  • If we do it right, the kmech_krb5 won't have to change ALL that much, but as rpcsec_gss gets zone-aware, so will kmech_krb5.
  • We may have to change interfaces into rpcsec, which means consumers (like nfssrv) may also need to change.
Actions #1

Updated by Jason King 4 months ago

I don't have a setup to check this, but another possibility worth investigating:

http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/gssapi/gssd_handle.c?r=6935f61b#138

If I'm understanding the code correctly, it appears to be creating a network socket to rpcbind to get the address of gssd. If it's connecting to the GZ's rpcbind, presumably it's going to return the info for the GZ's gssd instead of the zone's gssd.

Actions

Also available in: Atom PDF