date and time created 92/07/11 09:21:16 by heideman

[unix-history] / usr / src / sbin / mount_umap / mount_umap.8

.\"
.\" Copyright (c) 1992 The Regents of the University of California
.\" Copyright (c) 1990, 1992 Jan-Simon Pendry
.\" All rights reserved.
.\"
.\" This code is derived from software donated to Berkeley by
.\" Jan-Simon Pendry and from John Heidemann of the UCLA Ficus project.
.\"
.\"
.\" %sccs.include.redist.roff%
.\"
.\"     @(#)mount_umap.8	5.1 (Berkeley) %G%
.\"
.\"
.Dd 
.Dt MOUNT_UMAP 8
.Os BSD 4.4
.Sh NAME
.Nm mount_umap
.Nd sample file system layer
.Sh SYNOPSIS
.Nm mount_umap
.Op Fl F Ar fsoptions
.Ar target mount-point uid-mapfile gid-mapfile
.Sh DESCRIPTION
The
.Nm mount_umap
command is used to mount a sub-tree of an existing file system
that uses a different set of uids and gids than the local system.
Such a file system could be mounted from a remote site via NFS or
it could be a file system on removable media brought from some
foreign location that uses a different password file and yellow pages.
The
.Nm mount_umap
command uses a set of files provided by the user to make correspondences
between uids and gids in the sub-tree's original environment and
some other set of ids in the local environment.  For instance, user
smith might have uid 1000 in the original environment, while having
uid 2000 in the local environment.  The
.Nm mount_umap
command allows the subtree from smith's original environment to be
mapped in such a way that all files with owning uid 1000 look like
they are actually owned by uid 2000.  
.Pp
The target should be the current location of the sub-tree in the
local system's name space.  The mount-point should be a directory
where the mapped subtree is to be placed.  The uid-mapfile and
gid-mapfile describe the mappings to be made between identifiers.
Briefly, the format of these files is a count of the number of
mappings on the first line, with each subsequent line containing
a single mapping.  Each of these mappings consists of an id from
the original environment and the corresponding id in the local environment,
separated by white space.  The uid-mapfile should contain all uid
mappings, and the gid-mapfile should contain all gid mappings.
Any uids not mapped in the uid-mapfile will be treated as user NOBODY,
and any gids not mapped in the gid-mapfile will be treated as group
NULLGROUP.  At most 64 uids can be mapped for a given subtree, and
at most 16 groups can be mapped by a given subtree.
.Pp
The mapfiles can be located anywhere in the file hierarchy, but they
must be owned by root, and they must be writable only by root.  
.Nm mount_umap
will refuse to map the sub-tree if the ownership or permissions on
these files are improper.  It will also balk if the count of mappings
in the first line of the map files is not correct.
.Pp
The layer created by the
.Nm mount_umap
command is meant to serve as a simple example of file system layering.
It is not meant for production use.  The implementation is not very
sophisticated, and not particularly fast.

This command makes use of the layered file system, described
command makes a sub-tree of an existing filesystem visible
in another part of the global filesystem namespace,
while also performing mappings of uids and gids.  
This allows existing files and directories to be accessed
using a different pathname.
.Pp
Virtual file system sub-trees created by the null layer should
be identical to those created by the loopback
The virtual copy of a file system sub-tree created by the null
layer should be nearly identical to one created by
.Xr mount_lofs 8 .
The purpose of the null layer is to serve as a basis for future
layer development.
.Pp
An example of a layer constructed from the null layer is
the umap layer (see
.Xr mount_umap 8 ).
.Sh SEE ALSO
UCLA Technical Report CSD-910056,
"Stackable Layers: an Architecture for File System Development".
.Sh HISTORY
The
null file system layer
is
.Ud