Backing Up, Sharing, and Mounting Labeled Files (Task Map)

The following task map describes common tasks that are used to back up and restore data from labeled file systems, and to share and mount directories and files that are labeled.

How to Back Up Files in Trusted Extensions

1. Assume the Operator role.

   This role includes the Media Backup rights profile.

2. Use one of the following backup methods:

   • /usr/lib/fs/ufs/ufsdump for major backups

   • /usr/sbin/tar cT for small backups

   • A script calling either of these commands

     For example, the Budtool backup application calls the ufsdump command. See the ufsdump(1M) man page. For details on the T option to the tar command, see the tar(1) man page.

How to Restore Files in Trusted Extensions

1. Assume the System Administrator role.

   This role includes the Media Restore rights profile.

2. Use one of the following methods:

   • /usr/lib/fs/ufs/ufsrestore for major restores

   • /usr/sbin/tar xT for small restores

   • A script calling either of these commands

   For details on the T option to the tar command, see the tar(1) man page.

   ---

   Caution - Only these commands preserve labels.

   ---

How to Share Directories From a Labeled Zone

As in the Solaris OS, the Mounts and Shares tool in the Solaris Management Console is used to share and mount files from the global zone. The tool cannot be used to mount or share directories that originate in labeled zones. Create a dfstab file at the label of the zone, and then restart the zone to share the labeled directories.

Caution - Do not use proprietary names for shared file systems. The names of shared file systems are visible to every user.

Before You Begin

You must be superuser, or in the System Administrator role in the global zone on the file server.

1. Create a workspace at the label of the directory that is going to be shared.

   For details, see How to Add a Workspace at a Particular Label in Solaris Trusted Extensions User’s Guide.

2. Create a dfstab file in at the label of that zone.

   For each zone that will share a directory, repeat the following steps:

   1. Create the /etc/dfs directory in the zone.

      # mkdir -p /zone/zone-name/etc/dfs

   2. Open the trusted editor.

      For details, see How to Edit Administrative Files in Trusted Extensions.

   3. Type the full pathname of the dfstab file into the editor.

      # /zone/zone-name/etc/dfs/dfstab

   4. Add an entry to share a directory from that zone.

      The entry describes the directory from the perspective of the zone root path. For example, the following entry shares an application's files at the label of the containing zone:

      share -F nfs -o ro /viewdir/viewfiles

3. For each zone, share the directories by starting the zone.

   In the global zone, run one of the following commands for each zone. Each zone can share its directories in any of these ways. The actual sharing occurs when each zone is brought into the ready or running state.

   • If the zone is not in the running state and you do not want users to log in to the server at the label of the zone, set the zone state to ready.

     # zoneadm -z zone-name ready

   • If the zone is not in the running state and users are allowed to log in to the server at the label of the zone, boot the zone.

     # zoneadm -z zone-name boot

   • If the zone is already running, reboot the zone.

     # zoneadm -z zone-name reboot

4. Display the directories that are shared from your system.

   # showmount -e

5. To enable the client to mount the exported files, see How to NFS Mount Files in a Labeled Zone.

Example 17-2 Sharing the /export/share Directory at the PUBLIC Label

For applications that run at the label PUBLIC, the system administrator enables users to read the documentation in the /export/share directory of the public zone. The zone named public runs at the label PUBLIC.

First, the administrator creates a public workspace and edits the dfstab file.

# mkdir -p /zone/public/etc/dfs
# /usr/dt/bin/trusted_edit /zone/public/etc/dfs/dfstab

In the file, the administrator adds the following entry:

## Sharing PUBLIC user manuals
share -F nfs -o ro /export/appdocs

The administrator leaves the public workspace and returns to the Trusted Path workspace. Because users are not allowed to log in to this system, the administrator shares the files by putting the zone in the ready state:

# zoneadm -z public ready

Users can access the shared directories once the directories are mounted on the users' systems.

How to NFS Mount Files in a Labeled Zone

In Trusted Extensions, a labeled zone manages the mounting of files in its zone.

Files from unlabeled and labeled hosts can be mounted on a Trusted Extensions labeled host.

• To mount the files read/write from a single-label host, the assigned label of the remote host must be identical to the zone in which the file is being mounted.

• Files that are mounted by a higher-level zone are read-only.

• In Trusted Extensions, the auto_home configuration file is customized per zone. The file is named by zone name. For example, a system with a global zone and a public zone has two auto_home files, auto_home_global and auto_home_public.

Trusted Extensions uses the same mounting interfaces as the Solaris OS:

• To mount files at boot, use the /etc/vfstab file in the labeled zone.

• To mount files dynamically, use the mount command in the labeled zone.

• To automount home directories, use the auto_home_zone-name files.

• To automount other directories, use the standard automount maps. If the automount maps are in LDAP, use LDAP commands to manage them.

Before You Begin

You must be on the client system, in the zone at the label of the files that you want to mount. Unless you are using the automounter, you must be superuser, or be in the System Administrator role. To mount from lower-level servers, the zone must be configured with the net_mac_aware privilege.

• To NFS mount files in a labeled zone, use the following procedures.

  Most procedures include creating a workspace at a particular label. To create a workspace, see How to Add a Workspace at a Particular Label in Solaris Trusted Extensions User’s Guide.

  • Mount files dynamically.

    In the labeled zone, use the mount command. For an example of mounting files dynamically, see Example 17-3.

  • Mount files when the zone boots

    In the labeled zone, add the mounts to the vfstab file.

    For examples of mounting files when a labeled zone boots, see Example 17-4 and Example 17-5.

  • Mount home directories for systems that are administered with LDAP.
    1. At every label, add the user specifications to the auto_home_zone-name files.
    2. Then, use these files to populate the auto_home_zone-name database on the LDAP server.

    For an example, see Example 17-6.

  • Mount home directories for systems that are administered with files.
    1. Create and populate an /export/home/auto_home_lowest-labeled-zone-name file.
    2. Edit the /etc/auto_home_lowest-labeled-zone-name file to point to the newly populated file.
    3. Modify the /etc/auto_home_lowest-labeled-zone-name file in every higher-level zone to point to the file that you created in Step a.

    For an example, see Example 17-7.

Example 17-3 Mounting Files in a Labeled Zone by Using the mount Command

In this example, the system administrator mounts a remote file system from a public zone. The public zone is on a multilevel server.

After assuming the System Administrator role, the administrator creates a workspace at the label PUBLIC. In that workspace, the administrator runs the mount command.

# zonename
public
# mount -F nfs remote-sys:/zone/public/root/opt/docs /opt/docs

A single-label file server at the label PUBLIC also contains documents to be mounted:

# mount -F nfs public-sys:/publicdocs /opt/publicdocs

When the public zone of the remote-sys file server is in the ready or running state, the remote-sys files successfully mount on this system. When the public-sys file server is running, the files successfully mount.

Example 17-4 Mounting Files Read/Write in a Labeled Zone by Modifying the vfstab File

In this example, the system administrator mounts two remote file systems at the label PUBLIC in the local system's public zone when the public zone boots. One file system mount is from a multilevel system, and one file system mount is from a single-label system.

After assuming the System Administrator role, the administrator creates a workspace at the label PUBLIC. In that workspace, the administrator modifies the vfstab file in that zone.

## Writable books directories at PUBLIC
remote-sys:/zone/public/root/opt/docs  - /opt/docs  nfs  no  yes  rw
public-sys:/publicdocs    - /opt/publicdocs  nfs no yes rw

To access the files in the remote labeled zone of the multilevel system, the vfstab entry uses the zone root path of the remote system's public zone, /zone/public/root, as the directory pathname to the directories to mount. The path to the single-label system is identical to the path that would be used on a Solaris system.

In a terminal window at the label PUBLIC, the administrator mounts the files.

# mountall

Example 17-5 Mounting Lower-Level Files in a Labeled Zone by Modifying the vfstab File

In this example, the system administrator mounts a remote file system from a public zone in the local system's internal zone. After assuming the System Administrator role, the administrator creates a workspace at the label INTERNAL, then modifies the vfstab file in that zone.

## Readable books directory at PUBLIC
## ro entry indicates that PUBLIC docs can never be mounted rw in internal zone
remote-sys:/zone/public/root/opt/docs  - /opt/docs  nfs  no  yes  ro

To access the files in the remote labeled zone, the vfstab entry uses the zone root path of the remote system's public zone, /zone/public/root, as the directory pathname to the directories to mount.

From the perspective of a user in the internal zone, the files can be accessed at /opt/docs.

In a terminal window at the label INTERNAL, the administrator mounts the files.

# mountall

Example 17-6 Mounting Labeled Home Directories in a Network That Is Administered by Using LDAP

In this example, the system administrator enables a new user, ikuk, to access her home directory at every label. This site uses two home directory servers, and is administered by using LDAP. The second server contains the home directories for the users jdoe and pkai. The new user is added to this list.

First, after assuming the System Administrator role, the administrator modifies the auto_home_zone-name files in the /etc directory of the global zone to include the new user on the second home directory server.

## auto_home_global file
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&

## auto_home_internal file
## Mount the home directory from the internal zone of the NFS server
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&

## auto_home_public
## Mount the home directory from the public zone of the NFS server
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&

Next, to enable the users to log in at all labels, the administrator repeats these edits for the auto_home_zone-name files at every label.

Finally, after modifying every auto_home_zone-name file on this system, the administrator uses these files to add entries to the LDAP database.

Similar to the Solaris OS, the +auto_home_public entry in the /etc/auto_home_zone-name files directs the automounter to the LDAP entries. The auto_home_zone-name files on other systems on the network are updated from the LDAP database.

Example 17-7 Mounting a Lower-Level Home Directory on a System That Is Administered by Using Files

In this example, the system administrator enables users to access their home directories at every label. The labels at the site are PUBLIC, INTERNAL, and NEEDTOKNOW. This site uses two home directory servers, and is administered by using files. The second server contains the home directories for the users jdoe and pkai.

To accomplish this task, the system administrator defines the public zone NFS home directories in the public zone, and shares this configuration with the internal and needtoknow zones.

First, after assuming the System Administrator role, the administrator creates a workspace at the label PUBLIC. In this workspace, the administrator creates a new file, /export/home/auto_home_public. This file contains all the customized per-user NFS specification entries.

## /export/home/auto_home_public file at PUBLIC label
jdoe homedir2-server:/export/home/jdoe
pkai homedir2-server:/export/home/pkai
* homedir-server:/export/home/&

Second, the administrator modifies the /etc/auto_home_public file to point to this new file.

## /etc/auto_home_public file in the public zone
## Use /export/home/auto_home_public for the user entries
## +auto_home_public
+ /export/home/auto_home_public

This entry directs the automounter to use the contents of the local file.

Third, the administrator similarly modifies the /etc/auto_home_public file in the internal and needtoknow zones. The administrator uses the pathname to the public zone that is visible to the internal and needtoknow zones.

## /etc/auto_home_public file in the internal zone
## Use /zone/public/export/home/auto_home_public for PUBLIC user home dirs
## +auto_home_public
+ /zone/public/export/home/auto_home_public

## /etc/auto_home_public file in the needtoknow zone
## Use /zone/public/export/home/auto_home_public for PUBLIC user home dirs
## +auto_home_public
+ /zone/public/export/home/auto_home_public

When the administrator adds the new user ikuk, the addition is made to the /export/home/auto_home_public file at the PUBLIC label.

## /export/home/auto_home_public file at PUBLIC label
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&

The higher-level zones read down to obtain the per-user home directories from the lower-level public zone.

How to Troubleshoot Mount Failures in Trusted Extensions

Before You Begin

You must be in the zone at the label of the files that you want to mount. You must be the superuser, or in the System Administrator role.

1. Check the security attributes of the NFS server.

   Use the Security Templates tool in the Solaris Management Console at the appropriate scope. For details, see Initialize the Solaris Management Console Server in Trusted Extensions.

   1. Verify that the IP address of the NFS server is an assigned host in one of the security templates.

      The address might be directly assigned, or indirectly assigned through a wildcard mechanism. The address can be in a labeled template, or in an unlabeled template.

   2. Check the label that the template assigns to the NFS server.

      The label must be consistent with the label at which you are trying to mount the files.

2. Check the label of the current zone.

   If the label is higher than the label of the mounted file system, then you cannot write to the mount even if the remote file system is exported with read/write permissions. You can only write to the mounted file system at the label of the mount.

3. To mount file systems from an NFS server that is running earlier versions of Trusted Solaris software, do the following:
   • For a Trusted Solaris 1 NFS server, use the vers=2 and proto=udp options to the mount command.
   • For a Trusted Solaris 2.5.1 NFS server, use the vers=2 and proto=udp options to the mount command.
   • For a Trusted Solaris 8 NFS server, use the vers=3 and proto=udp options to the mount command.

   To mount file systems from any of these servers, the server must be assigned to an unlabeled template.