Steffen Weiberle wrote:
> I have a customer who is restricting NFS access to their data. Thus,
> instead of authorizing each non-global zone to be a client, would like
> to authorize only the global zone, and then lofs mount the NFS-mounted
> file system into the non-global zone.
> This work manually, but fails when configured via zonecfg.
> globalzone# zoneadm -z amp1 boot
> cannot verify fs /net/nfsserver/export/rw/code: NFS mounted file-system.
>          A local file-system must be used.
> zoneadm: zone amp1 failed to verify
> Per this old email, there is some reason for preventing this.
> Anybody know the details, and is doing this manually putting the
> non-global zones or the system at risk?

Some of the comments from the following RFE apply to this case
as well:

4963321 RFE: hosting root filesystems for zones on NFS servers

Since the comments aren't public I pasted the relevant stuff here:

     They're primariliy necessary due to (among other things) the fact
     that an NFS operation may translate to an over-the-wire call, and
     in fact may open a TCP/UDP connection to the server (if the mount
     has been inactive for long enough, or there is a failover, or a
     number of other reasons).

     While the semantics of process P in zone A doing a read(2) that
     causes zone B to do network activity on its behalf merely seemed
     odd (recall that zones have distinct network identities), the
     scenario of zone A performing a mount, and subsequently zone B
     opening a new connection to the server such that the client appears
     to have "migrated" from zone A to zone B seemed downright wrong.
     Besides this is the fact that NFS talks to various userland
     entities (such as statd and lockd) in the course of normal
     operation; a process in zone A using a mount belonging to zone B
     would naturally be unable to communicate with these processes due
     to our restrictions on inter-zone communication.

     Also recall that zone A and B don't necessarily share the same
     UID-to-user mappings, and have different host keys and principles
     which would cause severe problems when attempting to use something
     like secure or kerberized NFS.


zones-discuss mailing list

Reply via email to