From cfcc93eec947df1e540a41375912a5fa84ce75c3 Mon Sep 17 00:00:00 2001 From: rgrimes Date: Thu, 26 May 1994 06:35:07 +0000 Subject: BSD 4.4 Lite sbin Sources Note: XNSrouted and routed NOT imported here, they shall be imported with usr.sbin. --- sbin/mount_umapfs/Makefile | 11 ++ sbin/mount_umapfs/mount_umapfs.8 | 131 ++++++++++++++++++++++ sbin/mount_umapfs/mount_umapfs.c | 232 +++++++++++++++++++++++++++++++++++++++ sbin/mount_umapfs/umap_manual | 175 +++++++++++++++++++++++++++++ 4 files changed, 549 insertions(+) create mode 100644 sbin/mount_umapfs/Makefile create mode 100644 sbin/mount_umapfs/mount_umapfs.8 create mode 100644 sbin/mount_umapfs/mount_umapfs.c create mode 100644 sbin/mount_umapfs/umap_manual (limited to 'sbin/mount_umapfs') 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 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 +#include +#include + +#include + +#include +#include +#include +#include +#include + +#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} -- cgit v1.1