Section 6.6. File Systems


6.6. File Systems

Virtualization of storage in a zone is achieved by means of a restricted root, similar to the chroot(2) environment at the file system level. Processes running within a zone are limited to files and file systems that can be accessed from the restricted root. Unlike chroot, a zone is not escapable; once a process enters a zone, it and all of its children will be restricted to that zone and associated root.

The loopback file system (lofs) provides a useful tool for constructing a file system namespace for a zone. This is used to mount segments of a file system in multiple places within the namespace; for example, /usr could also be mounted underneath a zone root.

6.6.1. Configuration

Generally speaking, the set of file systems mounted in a zone is the set of the file systems mounted when the virtual platform is initialized plus the set of file systems mounted from within the application environment itself (for instance, the file systems specified in a zone's /etc/vfstab, as well as autofs and autofs-TRiggered mounts and mounts explicitly performed by zone administrator). Certain restrictions are placed on mounts performed from within the application environment to prevent the zone administrator from denying service to the rest of the system or otherwise negatively impacting other zones.

6.6.1.1. zonecfg File System Configuration

The global administrator can specify a number of mounts to be performed when the virtual platform is set up. Shown below is the interface for specifying that /dev/ dsk/c0t0d0s7 in the global zone is to be mounted as /var/tmp in zone my-zone and that the file system type to use should be UFS, mounted with logging enabled.

zonecfg:newzone> add fs zonecfg:newzone:fs> set dir=/var/tmp zonecfg:newzone:fs> set special=/dev/dsk/c0t0d0s7 zonecfg:newzone:fs> set raw=/dev/rdsk/c0t0d0s7 zonecfg:newzone:fs> set type=ufs zonecfg:newzone:fs> set options=noatime zonecfg:newzone:fs> end zonecfg:newzone> info fs dir=/var/tmp fs:         dir: /var/tmp         special: /dev/dsk/c0t0d0s7         raw: /dev/rdsk/c0t0d0s7         type: ufs         options: [noatime] 


File systems loopback-mounted (via lofs) into a zone must be mounted with the -o nodevices option to prevent dev_t proliferation.

6.6.2. Size Restrictions

The Zones infrastructure does not attempt to provide limits, through zone-wide quotas or otherwise, on how much disk space can be consumed by a zone. The global administrator is responsible for space restriction. Administrators interested in this functionality have a number of options, including the following:

  • lofi. A global administrator may place the zone on a lofi(7D)-mounted partition, limiting the amount of space consumable by the zone to that of the file used by lofi.

  • Soft partitions. Disk slices or logical volumes can be divided into up to 8192 partitions. A global administrator can use these partitions as zone roots, and thus limit per-zone disk consumption.

  • ZFS. A virtually unlimited number of file systems can be created from a storage pool; this is also an option for global administrators.

6.6.3. File System-Specific Issues

There are certain security restrictions on mounting certain file systems from within a zone, while other file systems exhibit special behavior when mounted in a zone. The modified file systems are summarized below.

  • autofs. Each zone runs its own copy of automountd, with the automaps and timeouts under the zone administrator's control. Since the zone's file system namespace is really only a subset of that of the global zone, the global zone could possibly create automaps that reference the non-global zone or traverse into non-global zones and attempt to trigger mounts. This would cause a number of complications, which we circumvent by saying that triggering a mount in another zone (that is, crossing an autofs mount point for a non-global zone from the global zone) is disallowed and that the lookup request fails. Note that such situations cannot arise without the participation of the global zone.

    Certain autofs mounts are created in the kernel when another mount is triggered. For example, the autofs mount /net/rankine/export1 is created in the kernel when the NFS mount /net/rankine is triggered. Such mounts cannot be removed with the regular umount(2) interface since they must be mounted or unmounted as a group to preserve semantics. A kernel thread periodically wakes up and attempts to communicate with automountd in order to remove such mounts, but no interface explicitly attempts to remove such mount points. Zones implements a private kernel interface to provide this functionality, which is necessary for zone shutdown.

  • mntfs. mntfs is modified such that the set of file systems visible via mnttab(4) from within a non-global zone is the set of file systems mounted in the zone, plus an entry for "/". Mount points with a "special device" (that is, /dev/rdsk/c0t0d0s0) not accessible from within the zone have their special device set to the same as the mount point. mntfs takes a zone argument similar to what is described for procfs in Section 6.5.3. All mounts in the system are visible from the global zone's mnttab.

    When mounted from within a zone, mntfs file systems behave as though mounted with "-o zone='zonename'".

  • NFS. mounts from within a zone behave (implicitly) as though mounted with the -o nodevices option.

  • procfs. See Section 6.5.3 for a full description of /proc modifications. When mounted from within a zone, procfs file systems behave as though mounted with -o zone='zonename'.

  • tmpfs. Although a "virtual" file system, tmpfs could be used by a malicious zone administrator to consume all available swap on the system.

    In addition to consuming all of swap and thus causing a denial of service, a zone may consume a lot of physical memory on the machine by creating many small files, exploiting the fact that inodes on a tmpfs file system are always kept in core. This is actually a problem in stock Solaris as well, although certain threshold values in the kernel prevent tmpfs from using all of physical memory. In the absence of explicit per-zone limits, one zone would be able to cause tmpfs file creations in another zone to fail.

  • lofs. Read-only lofs mounts traditionally did not prevent read-write access to files. An enhancement allows zones to take advantage of lofs during zone installation.

    Note that the scope of what can be mounted via lofs is limited to the portion of the file system visible to the zone. Hence, there are no restrictions on lofs mounts in a zone.

  • UFS, hsfs, pcfs. These are file system types that (due to bad metadata or other problems with the backing physical device) may cause the system as a whole to fail and hence cannot safely be mounted from within a zone. They may, however be mounted in a zone if an appropriate block device is exported to the zone. Hence, for such file systems to exist within a zone they must either be mounted directly by or with the explicit consent (expressed in the zone configuration profile) of the global zone administrator.

6.6.4. File System Traversal Issues

Recall that a zone's file system namespace is a subset of that accessible from the global zone. Global zone processes accessing a zone's file system namespace can open up a host of problems on the system.

Unprivileged processes in the global zone are prevented from traversing a non-global zone's file system hierarchy by insisting on the zone root's parent directory being owned, readable, writable, and executable by root only, and restricting access to directories exported by /proc (see Section 6.5.3).

The following are highlighted as potential issues that are avoided by restricted access into the zone's file system namespace but that should be taken into account by the global administrator.

  • Security. Since zone administrators can set the setuid bit on executables, an unprivileged process in the global zone could coordinate with a privileged process in a non-global zone, effectively giving the process in the global zone all privileges.

  • Zone startup and shutdown. Cross-zone file accesses may cause certain complications during zone shutdown. As described in Section 6.5.3, all file systems mounted in the zone's namespace must unmounted before the zone can be fully shut down. While certain file systems (such as NFS) support forcible unmounts, many do not. File systems with files open because of access from the global zone will not be able to be unmounted; hence, cross-zone access can interfere with zone rebooting or shutting down.

    Furthermore, it is not possible to boot a zone if preestablished mounts would end up visible from within the zone.

  • autofs. As noted earlier in Section 6.6.3, attempting to access autofs nodes mounted for another zone will fail. The global administrator should thus take care to not have automaps that descend into other zones.

The following example illustrates the per-zone mnttab.

global# zoneadm list -v       ID NAME             STATE            PATH        0 global           running          /      100 my-zone          running          /aux0/my-zone global# cat /etc/mnttab /dev/dsk/c0t0d0s0       /       ufs rw,intr,largefiles,logging,xattr,oner- ror=panic,suid,dev=800000 1028243575 /devices        /devices        devfs   dev=9cbc0000    1028243566 /proc   /proc   proc    dev=9cc00000    1028243572 mnttab  /etc/mnttab     mntfs   dev=9ccc0000     1028243572 fd      /dev/fd fd      rw,suid,dev=9cd00001     1028243575 swap    /var/run        tmpfs   xattr,dev=1      1028243596 swap    /tmp    tmpfs   xattr,dev=2     1028243598 proc    /aux0/my-zone/proc       proc     zone=my-zone,dev=9cc00000 1028570870 fd      /aux0/my-zone/dev/fd     fd       rw,suid,dev=9cd00004 1028570870 /opt    /aux0/my-zone/opt        lofs     rw,suid,dev=800000 1028570870 /sbin   /aux0/my-zone/sbin       lofs     rw,suid,dev=800000 1028570870 swap    /aux0/my-zone/tmp        tmpfs    xattr,dev=7      1028570870 swap    /aux0/my-zone/var/run    tmpfs    xattr,dev=8      1028570870 mnttab  /aux0/my-zone/etc/mnttab mntfs    zone=my-zone,dev=9ccc0000 1028570870 taxman.eng:/web /aux0/my-zone/net/taxman.eng/web nfs intr,nosuid,grpid,xattr,dev=9cec0020    1028572145 jurassic.eng:/export/home14/ozgur       /home/ozgur      nfs intr,nosuid,noquota,xattr,dev=9cec0043  1028939560 global# cat /aux0/my-zone/etc/mnttab /       /       ufs     rw,intr,largefiles,logging,xattr,onerror=panic,suid,dev=800000 1028243575 /usr    /usr    lofs    rw,suid,dev=800000      1028243598 proc    /proc   proc    zone=my-zone,dev=9cc00000     1028570870 fd      /dev/fd fd      rw,suid,dev=9cd00004    1028570870 /opt    /opt    lofs    rw,suid,dev=800000      1028570870 /sbin   /sbin   lofs    rw,suid,dev=800000      1028570870 swap    /tmp    tmpfs   xattr,dev=7     1028570870 swap    /var/run        tmpfs   xattr,dev=8     1028570870 mnttab  /etc/mnttab     mntfs   zone=my-zone,dev=9ccc0000     1028570870 taxman.eng:/web /net/taxman.eng/web     nfs intr,nosuid,grpid,xattr,dev=9cec0020 145 





SolarisT Internals. Solaris 10 and OpenSolaris Kernel Architecture
Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture (2nd Edition)
ISBN: 0131482092
EAN: 2147483647
Year: 2004
Pages: 244

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net