BSD 4.4 Lite sbin Sources

Note:  XNSrouted and routed NOT imported here, they shall be imported with
usr.sbin.

4 files changed, 549 insertions, 0 deletions

diff --git a/sbin/mount_umapfs/Makefile b/sbin/mount_umapfs/Makefile
new file mode 100644
index 0000000..af1bf2f
--- /dev/null
+++ b/sbin/mount_umapfs/Makefile
@@ -0,0 +1,11 @@
+#	@(#)Makefile	8.3 (Berkeley) 3/27/94
+
+PROG=	mount_umap
+SRCS=	mount_umap.c getmntopts.c
+MAN8=	mount_umap.0
+
+MOUNT=	${.CURDIR}/../mount
+CFLAGS+= -I/sys -I${MOUNT}
+.PATH:	${MOUNT}
+
+.include <bsd.prog.mk>
diff --git a/sbin/mount_umapfs/mount_umapfs.8 b/sbin/mount_umapfs/mount_umapfs.8
new file mode 100644
index 0000000..e90ce26
--- /dev/null
+++ b/sbin/mount_umapfs/mount_umapfs.8
@@ -0,0 +1,131 @@
+.\" Copyright (c) 1992, 1993, 1994
+.\"	The Regents of the University of California.  All rights reserved.
+.\" 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.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"	@(#)mount_umap.8	8.3 (Berkeley) 3/27/94
+.\"
+.Dd "March 27, 1994"
+.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 o Ar options
+.Ar target
+.Ar mount-point
+.Ar uid-mapfile
+.Ar 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.
+.Pp
+The options are as follows:
+.Bl -tag -width indent
+.It Fl o
+Options are specified with a
+.Fl o
+flag followed by a comma separated string of options.
+See the
+.Xr mount 8
+man page for possible options and their meanings.
+.El
+.Pp
+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
+.Em target 
+should be the current location of the sub-tree in the
+local system's name space.  
+.Em mount-point 
+should be a directory
+where the mapped subtree is to be placed.  
+.Em uid-mapfile 
+and
+.Em 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.  
+.Em uid-mapfile 
+should contain all uid
+mappings, and 
+.Em gid-mapfile 
+should contain all gid mappings.
+Any uids not mapped in 
+.Em uid-mapfile 
+will be treated as user NOBODY,
+and any gids not mapped in 
+.Em 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.
+.Sh SEE ALSO
+.Xr mount 8 ,
+.Xr mount_null 8 ,
+.Xr mount_lofs 8
+.Sh HISTORY
+The
+.Nm mount_umap
+utility first appeared in 4.4BSD.
diff --git a/sbin/mount_umapfs/mount_umapfs.c b/sbin/mount_umapfs/mount_umapfs.c
new file mode 100644
index 0000000..a069fe5
--- /dev/null
+++ b/sbin/mount_umapfs/mount_umapfs.c
@@ -0,0 +1,232 @@
+/*
+ * Copyright (c) 1992, 1993, 1994
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * This code is derived from software donated to Berkeley by
+ * Jan-Simon Pendry.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *    must display the following acknowledgement:
+ *	This product includes software developed by the University of
+ *	California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifndef lint
+char copyright[] =
+"@(#) Copyright (c) 1992, 1993, 1994\n\
+	The Regents of the University of California.  All rights reserved.\n";
+#endif /* not lint */
+
+#ifndef lint
+static char sccsid[] = "@(#)mount_umap.c	8.3 (Berkeley) 3/27/94";
+#endif /* not lint */
+
+#include <sys/param.h>
+#include <sys/mount.h>
+#include <sys/stat.h>
+
+#include <miscfs/umapfs/umap.h>
+
+#include <err.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#include "mntopts.h"
+
+#define ROOTUSER 0
+/*
+ * This define controls whether any user but the superuser can own and
+ * write mapfiles.  If other users can, system security can be gravely
+ * compromised.  If this is not a concern, undefine SECURITY.
+ */
+#define MAPSECURITY 1
+
+/*
+ * This routine provides the user interface to mounting a umap layer.
+ * It takes 4 mandatory parameters.  The mandatory arguments are the place 
+ * where the next lower level is mounted, the place where the umap layer is to
+ * be mounted, the name of the user mapfile, and the name of the group
+ * mapfile.  The routine checks the ownerships and permissions on the
+ * mapfiles, then opens and reads them.  Then it calls mount(), which
+ * will, in turn, call the umap version of mount. 
+ */
+
+struct mntopt mopts[] = {
+	MOPT_STDOPTS,
+	{ NULL }
+};
+
+void	usage __P((void));
+
+int
+main(argc, argv)
+	int argc;
+	char *argv[];
+{
+	static char not[] = "; not mounted.";
+	struct stat statbuf;
+	struct umap_args args;
+        FILE *fp, *gfp;
+        u_long gmapdata[GMAPFILEENTRIES][2], mapdata[MAPFILEENTRIES][2];
+	int ch, count, gnentries, mntflags, nentries;
+	char *gmapfile, *mapfile, *source, *target, buf[20];
+
+	mntflags = 0;
+	mapfile = gmapfile = NULL;
+	while ((ch = getopt(argc, argv, "g:o:u:")) != EOF)
+		switch (ch) {
+		case 'g':
+			gmapfile = optarg;
+			break;
+		case 'o':
+			getmntopts(optarg, mopts, &mntflags);
+			break;
+		case 'u':
+			mapfile = optarg;
+			break;
+		case '?':
+		default:
+			usage();
+		}
+	argc -= optind;
+	argv += optind;
+
+	if (argc != 2 || mapfile == NULL || gmapfile == NULL)
+		usage();
+
+	source = argv[0];
+	target = argv[1];
+
+	/* Read in uid mapping data. */
+	if ((fp = fopen(mapfile, "r")) == NULL)
+		err(1, "%s%s", mapfile, not);
+
+#ifdef MAPSECURITY
+	/*
+	 * Check that group and other don't have write permissions on
+	 * this mapfile, and that the mapfile belongs to root. 
+	 */
+	if (fstat(fileno(fp), &statbuf))
+		err(1, "%s%s", mapfile, not);
+	if (statbuf.st_mode & S_IWGRP || statbuf.st_mode & S_IWOTH) {
+		strmode(statbuf.st_mode, buf);
+		err(1, "%s: improper write permissions (%s)%s",
+		    mapfile, buf, not);
+	}
+	if (statbuf.st_uid != ROOTUSER)
+		errx(1, "%s does not belong to root%s", mapfile, not);
+#endif /* MAPSECURITY */
+
+	if ((fscanf(fp, "%d\n", &nentries)) != 1)
+		errx(1, "%s: nentries not found%s", mapfile, not);
+	if (nentries > MAPFILEENTRIES)
+		errx(1,
+		    "maximum number of entries is %d%s", MAPFILEENTRIES, not);
+#if 0
+	(void)printf("reading %d entries\n", nentries);
+#endif
+	for (count = 0; count < nentries; ++count) {
+		if ((fscanf(fp, "%lu %lu\n",
+		    &(mapdata[count][0]), &(mapdata[count][1]))) != 2) {
+			if (ferror(fp))
+				err(1, "%s%s", mapfile, not);
+			if (feof(fp))
+				errx(1, "%s: unexpected end-of-file%s",
+				    mapfile, not);
+			errx(1, "%s: illegal format (line %d)%s",
+			    mapfile, count + 2, not);
+		}
+#if 0
+		/* Fix a security hole. */
+		if (mapdata[count][1] == 0)
+			errx(1, "mapping id 0 not permitted (line %d)%s",
+			    count + 2, not);
+#endif
+	}
+
+	/* Read in gid mapping data. */
+	if ((gfp = fopen(gmapfile, "r")) == NULL)
+		err(1, "%s%s", gmapfile, not);
+
+#ifdef MAPSECURITY
+	/*
+	 * Check that group and other don't have write permissions on
+	 * this group mapfile, and that the file belongs to root. 
+	 */
+	if (fstat(fileno(gfp), &statbuf))
+		err(1, "%s%s", gmapfile, not);
+	if (statbuf.st_mode & S_IWGRP || statbuf.st_mode & S_IWOTH) {
+		strmode(statbuf.st_mode, buf);
+		err(1, "%s: improper write permissions (%s)%s",
+		    gmapfile, buf, not);
+	}
+	if (statbuf.st_uid != ROOTUSER)
+		errx(1, "%s does not belong to root%s", gmapfile, not);
+#endif /* MAPSECURITY */
+
+	if ((fscanf(fp, "%d\n", &gnentries)) != 1)
+		errx(1, "nentries not found%s", gmapfile, not);
+	if (gnentries > MAPFILEENTRIES)
+		errx(1,
+		    "maximum number of entries is %d%s", GMAPFILEENTRIES, not);
+#if 0
+	(void)printf("reading %d group entries\n", gnentries);
+#endif
+
+	for (count = 0; count < gnentries; ++count)
+		if ((fscanf(fp, "%lu %lu\n",
+		    &(gmapdata[count][0]), &(gmapdata[count][1]))) != 2) {
+			if (ferror(fp))
+				err(1, "%s%s", gmapfile, not);
+			if (feof(fp))
+				errx(1, "%s: unexpected end-of-file%s",
+				    gmapfile, not);
+			errx(1, "%s: illegal format (line %d)%s",
+			    gmapfile, count + 2, not);
+		}
+
+
+	/* Setup mount call args. */
+	args.target = source;
+	args.nentries = nentries;
+	args.mapdata = mapdata;
+	args.gnentries = gnentries;
+	args.gmapdata = gmapdata;
+
+	if (mount(MOUNT_UMAP, argv[1], mntflags, &args))
+		err(1, NULL);
+	exit(0);
+}
+
+void
+usage()
+{
+	(void)fprintf(stderr,
+"usage: mount_umap [-o options] -u usermap -g groupmap target_fs mount_point\n");
+	exit(1);
+}
diff --git a/sbin/mount_umapfs/umap_manual b/sbin/mount_umapfs/umap_manual
new file mode 100644
index 0000000..059939f
--- /dev/null
+++ b/sbin/mount_umapfs/umap_manual
@@ -0,0 +1,175 @@
+
+\appendix
+\section{The umap Layer} \label{sect:umap}
+
+\subsection{Introduction}
+
+Normally, the file system is expected to span a single administrative domain.
+An administrative domain, for these purposes, is a machine or set of
+machines that share common password file information, usually through
+the yellow pages mechanism.  File hierarchies that span more 
+than one domain leads to certain problems, since the same numerical 
+UID in one domain may correspond to a different user in another domain.  
+If the system administrator is very careful to ensure that both domains 
+contain identical user ID information, The umap layer can be used to
+run between those domains without changes
+
+The umap layer is a file system layer that sits on top of the normal
+file layer.  The umap layer maps Unix-style UIDs from
+one domain into the UIDs in the other domain.  By setting up the mappings
+properly, the same user with different UIDs in two domains can be seen
+as the same user, from the system point of view, or, conversely, two
+different users with the same UID in the two domains can be distinguished.
+
+First, we define some terms.  ``User'' refers to the human (or daemon) that
+has privileges to login, run programs, and access files.  ``UID''refers to
+the numerical identifier that uniquely identifies the user within a
+single domain.  ``Login name'' refers to the character string the user
+types to log into the system.  ``GID'' refers to the numerical group
+identifier used by Unix systems to identify groups of users.  ``Group
+name'' is the character string name attached to a particular GID in the
+local {\sf /etc/groups} file or the yellow pages groups file.
+
+In order for the umap layer to work properly, all users 
+in either domain must have password file entries in both domains.  
+They do not, however, have to have the same numerical UID, nor even the 
+same character string login name (the latter is highly recommended, 
+if possible, however).  Any user not having a UID in one domain will be 
+treated as the special user NOBODY by the other domain, probably with 
+undesirable consequences.  Any user not owning any files in the shared
+sub-trees need not be given a UID in the other domain.
+
+Groups work similarly.  The umap layer can translate group ID's between
+domains in the same manner as UID's.  Again, any group that wishes to
+participate must have a group ID in both domains,
+though it need not be the same GID in both.  If a group in one domain is not
+known in the other domain, that group will be treated as being NULLGROUP.
+The umap layer has no provisions for enrolling UID's from other domains
+as group members, but, since each user from each domain must have some
+UID in every domain, the UID in the local domain can be used to enroll
+the user in the local groups.  
+
+NOBODY and NULLGROUP are special reserved UID's and GID's, respectively.
+NOBODY is user 32767.  NULLGROUP is group 65534.  If the system administrator
+wants to have an appropriate text string appear when these UID's are
+encountered by programs like {\sf ls -l}, he should add these values to
+the password and {\sf /etc/groups} file, or to the appropriate yellow pages.  
+If these IDs are already in use in that domain, different values can be 
+used for NOBODY and NULLGROUP, but that will require a recompilation of 
+the umap layer code and, as a result, the entire kernel.  These 
+values are defined in the {\sf umap\_info.h} file, kept with the rest of the 
+umap source code.
+
+When the umap layer is in use, one of the participating domains is declared 
+to be the master.  All UID and GID information stored for participating files 
+will be stored in vnodes using its mappings, no matter what site the copies of 
+the files are stored at.  The master domain therefore need not run a copy 
+of the umap layer, as it already has all of the correct mappings.  All 
+other domains must run a umap layer on top of any other layers they use.
+
+\subsection{Setting Up a umap Layer}
+
+The system administrator of a system needing to use the umap layer 
+must take several actions.  
+First, he must create files containing the necessary UID
+and GID mappings.  There is a separate file for user and group IDs.  The
+format of the files is the same.  The first line contains the total number
+of entries in the file.  Each subsequent line contains one mapping.  A
+mapping line consists of two numerical UIDs, separated by white space.
+The first is the UID of a user on the local machine.  The second is the
+UID for the same user on the master machine.  The maximum number of users
+that can be mapped for a single shared sub-tree is 64.  The maximum number of
+groups that can be mapped for a single sub-tree is 16.  These constants
+are set in the {\sf umap\_info.h} file, and can be changed, but changing them
+requires recompilation.  Separate mapping files can be used for each shared 
+subtree, or the same mapping files can be shared by several sub-trees.
+
+Below is a sample UID mapping file.  There are four entries.  UID 5 is mapped
+to 5, 521 to 521, and 7000 to 7000.  UID 2002 is mapped to 604.  On this
+machine, the UID's for users 5, 521, and 7000 are the same as on the master,
+but UID 2002 is for a user whose UID on the master machine is 604.  All
+files in the sub-tree belonging to that user have UID 604 in their inodes,
+even on this machine, but the umap layer will ensure that anyone running
+under UID 2002 will have all files in this sub-tree owned by 604 treated as if 
+they were owned by 2002.  An {\sf ls -l} on a file owned by 604 in this sub-tree
+will show the login name associated with UID 2002 as the owner.
+
+\noindent4\newline
+5 5\newline
+521 521\newline
+2002 604\newline
+7000 7000\newline
+
+The user and group mapping files should be owned by the root user, and
+should be writable only by that user.  If they are not owned by root, or
+are writable by some other user, the umap mounting command will abort.
+
+Normally, the sub-treeis grafted directly into the place in
+the file hierarchy where the it should appear to users.Using the umap
+layer requires that the sub-tree be grafted somewhere else, and
+the umap layer be mounted in the desired position in the file hierarchy.
+Depending on the situation, the underlying sub-tree can be wherever is
+convenient.
+
+\subsection{Troubleshooting umap Layer Problems}
+
+The umap layer code was not built with special convenience or
+robustness in mind, as it is expected to be superseded with a better
+user ID mapping strategy in the near future.  As a result, it is not
+very forgiving of errors in being set up.  Here are some possible
+problems, and what to do about them.
+
+\begin{itemize}
+
+
+\item{Problem: A file belongs to NOBODY, or group NULLGROUP.
+
+Fixes: The mapping files don't know about this file's real user or group.  
+Either they are not in the mapping files, or the counts on the number of 
+entries in the mapping files are too low, so entries at the end (including 
+these) are being ignored.  Add the entries or fix the counts, and either
+unmount and remount the sub-tree, or reboot.}
+
+\item{Problem: A normal operation does not work.
+
+Fixes: Possibly, some mapping has not been set properly.  Check to
+see which files are used by the operation and who they appear to be
+owned by.  If they are owned by NOBODY or some other suspicious user,
+there may be a problem in the mapping files.  Be sure to check groups,
+too.  As above, if the counts of mappings in the mapping files are lower 
+than the actual numbers of pairs, pairs at the end of the file will be 
+ignored.  If any changes are made in the mapping files, you will need to 
+either unmount and remount or reboot before they will take effect.
+
+Another possible problem can arise because not all Unix utilities
+rely exclusively on numeric UID for identification.  For instance, 
+SCCS saves the login name in files.  If a user's login name on two machines
+isn't the same, SCCS may veto an operation even though Unix file permissions,
+as checked by the umap layer, may say it's OK.  There's not much to be
+done in such cases, unless the login name can be changed or one fiddles
+improperly with SCCS information.  There may be other, undiscovered cases
+where similar problems arise, some of which may be even harder to handle.}
+
+\item{Problem: Someone has access permissions he should not have.
+
+Fixes: This is probably caused by a mistake in the mapping files.  Check 
+both user and group mapping files.  If any changes are made in the mapping 
+files, you will need to unmount and remount the sub-tree or reboot before they 
+will take effect.}
+
+\item{Problem: {\sf ls -l} (or a similar program) shows the wrong user for a file.
+
+Fixes: Probably a mistake in the mapping files.  In particular, if
+two local UIDs are mapped to a single master UID, stat calls will assign
+ownership to the first local UID occurring in the file, which may or may
+not be what was intended.  (Generally speaking, mapping two local UIDs to
+a single master UID is a bad idea, but the software will not prevent it.
+Similarly, mapping a single local UID to two master UIDs is a bad idea,
+but will not be prevented.  In this case, only the first mapping of the
+local UID will be done.  The second, and all subsequent ones, will be 
+ignored.) If any changes are made in the mapping files, you will need to 
+unmount and remount the sub-tree or reboot before they will take effect.}
+
+\end{itemize}
+
+\end{document}