From: Matthew Dillon Date: Sat, 13 May 2006 05:10:42 +0000 (+0000) Subject: Remove mount_umap. X-Git-Tag: v2.0.1~4945 X-Git-Url: https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff_plain/046eca4acd4464e06185e8fa328c61365096c5ee Remove mount_umap. --- diff --git a/sbin/Makefile b/sbin/Makefile index 22d668a868..1d40bbd6ab 100644 --- a/sbin/Makefile +++ b/sbin/Makefile @@ -1,6 +1,6 @@ # @(#)Makefile 8.5 (Berkeley) 3/31/94 # $FreeBSD: src/sbin/Makefile,v 1.77.2.9 2002/08/08 09:03:46 ru Exp $ -# $DragonFly: src/sbin/Makefile,v 1.10 2005/12/21 16:33:20 corecode Exp $ +# $DragonFly: src/sbin/Makefile,v 1.11 2006/05/13 05:10:40 dillon Exp $ # # XXX MISSING: icheck ncheck @@ -48,7 +48,6 @@ SUBDIR= adjkerntz \ mount_portal \ mount_std \ mount_udf \ - mount_umap \ mount_union \ mountd \ natd \ diff --git a/sbin/mount_umap/Makefile b/sbin/mount_umap/Makefile deleted file mode 100644 index 13fe6e441b..0000000000 --- a/sbin/mount_umap/Makefile +++ /dev/null @@ -1,13 +0,0 @@ -# @(#)Makefile 8.3 (Berkeley) 3/27/94 -# $FreeBSD: src/sbin/mount_umap/Makefile,v 1.6.6.1 2001/04/25 10:58:40 ru Exp $ -# $DragonFly: src/sbin/mount_umap/Attic/Makefile,v 1.2 2003/06/17 04:27:33 dillon Exp $ - -PROG= mount_umap -SRCS= mount_umap.c getmntopts.c -MAN= mount_umap.8 - -MOUNT= ${.CURDIR}/../mount -CFLAGS+= -I${.CURDIR}/../../sys -I${MOUNT} -.PATH: ${MOUNT} - -.include diff --git a/sbin/mount_umap/mount_umap.8 b/sbin/mount_umap/mount_umap.8 deleted file mode 100644 index 32dfdf7695..0000000000 --- a/sbin/mount_umap/mount_umap.8 +++ /dev/null @@ -1,141 +0,0 @@ -.\" 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.4 (Berkeley) 5/1/95 -.\" $FreeBSD: src/sbin/mount_umap/mount_umap.8,v 1.10.2.3 2001/12/20 16:44:17 ru Exp $ -.\" $DragonFly: src/sbin/mount_umap/Attic/mount_umap.8,v 1.3 2006/02/17 19:33:33 swildner Exp $ -.\" -.Dd May 1, 1995 -.Dt MOUNT_UMAP 8 -.Os -.Sh NAME -.Nm mount_umap -.Nd sample file system layer -.Sh SYNOPSIS -.Nm -.Op Fl o Ar options -.Fl u Ar uid-mapfile -.Fl g Ar gid-mapfile -.Ar target -.Ar mount-point -.Sh DESCRIPTION -The -.Nm -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 -.Nm -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 -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 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. -.It Ar target -Should be the current location of the sub-tree in the -local system's name space. -.It Ar mount-point -Should be a directory -where the mapped subtree is to be placed. -.It Fl u Ar uid-mapfile -.It Fl g Ar 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 in -the local environment and the corresponding id from the original environment, -separated by white space. -.Ar Uid-mapfile -should contain all uid -mappings, and -.Ar gid-mapfile -should contain all gid mappings. -Any uids not mapped in -.Ar uid-mapfile -will be treated as user NOBODY, -and any gids not mapped in -.Ar 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. -.El -.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 -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 -.Sh HISTORY -The -.Nm -utility first appeared in -.Bx 4.4 . -.Sh BUGS -THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) -AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR -OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET. -.Pp -This code also needs an owner in order to be less dangerous - serious -hackers can apply by sending mail to -.Aq hackers@FreeBSD.org -and announcing -their intent to take it over. diff --git a/sbin/mount_umap/mount_umap.c b/sbin/mount_umap/mount_umap.c deleted file mode 100644 index a21123a8f7..0000000000 --- a/sbin/mount_umap/mount_umap.c +++ /dev/null @@ -1,240 +0,0 @@ -/* - * 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. - * - * @(#) Copyright (c) 1992, 1993, 1994 The Regents of the University of California. All rights reserved. - * @(#)mount_umap.c 8.5 (Berkeley) 4/26/95 - * $FreeBSD: src/sbin/mount_umap/mount_umap.c,v 1.15 1999/10/09 11:54:13 phk Exp $ - * $DragonFly: src/sbin/mount_umap/Attic/mount_umap.c,v 1.7 2004/12/18 21:43:39 swildner Exp $ - */ - -#include -#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. - */ - -static struct mntopt mopts[] = { - MOPT_STDOPTS, - { NULL } -}; - -static void usage(void) __dead2; - -int -main(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, buf[20]; - char source[MAXPATHLEN], target[MAXPATHLEN]; - struct vfsconf vfc; - int error; - - mntflags = 0; - mapfile = gmapfile = NULL; - while ((ch = getopt(argc, argv, "g:o:u:")) != -1) - switch (ch) { - case 'g': - gmapfile = optarg; - break; - case 'o': - getmntopts(optarg, mopts, &mntflags, 0); - break; - case 'u': - mapfile = optarg; - break; - case '?': - default: - usage(); - } - argc -= optind; - argv += optind; - - if (argc != 2 || mapfile == NULL || gmapfile == NULL) - usage(); - - /* resolve both target and source with realpath(3) */ - checkpath(argv[0], source); - checkpath(argv[1], target); - - /* Read in uid mapping data. */ - if ((fp = fopen(mapfile, "r")) == NULL) - err(EX_NOINPUT, "%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(EX_OSERR, "%s%s", mapfile, not); - if (statbuf.st_mode & S_IWGRP || statbuf.st_mode & S_IWOTH) { - strmode(statbuf.st_mode, buf); - err(EX_NOPERM, "%s: improper write permissions (%s)%s", - mapfile, buf, not); - } - if (statbuf.st_uid != ROOTUSER) - errx(EX_NOPERM, "%s does not belong to root%s", mapfile, not); -#endif /* MAPSECURITY */ - - if ((fscanf(fp, "%d\n", &nentries)) != 1) - errx(EX_DATAERR, "%s: nentries not found%s", mapfile, not); - if (nentries > MAPFILEENTRIES) - errx(EX_DATAERR, - "maximum number of entries is %d%s", MAPFILEENTRIES, not); -#if 0 - 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(EX_OSERR, "%s%s", mapfile, not); - if (feof(fp)) - errx(EX_DATAERR, "%s: unexpected end-of-file%s", - mapfile, not); - errx(EX_DATAERR, "%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(EX_NOINPUT, "%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(EX_OSERR, "%s%s", gmapfile, not); - if (statbuf.st_mode & S_IWGRP || statbuf.st_mode & S_IWOTH) { - strmode(statbuf.st_mode, buf); - err(EX_NOPERM, "%s: improper write permissions (%s)%s", - gmapfile, buf, not); - } - if (statbuf.st_uid != ROOTUSER) - errx(EX_NOPERM, "%s does not belong to root%s", gmapfile, not); -#endif /* MAPSECURITY */ - - if ((fscanf(gfp, "%d\n", &gnentries)) != 1) - errx(EX_DATAERR, "%s: nentries not found%s", gmapfile, not); - if (gnentries > MAPFILEENTRIES) - errx(EX_DATAERR, - "maximum number of entries is %d%s", GMAPFILEENTRIES, not); -#if 0 - printf("reading %d group entries\n", gnentries); -#endif - - for (count = 0; count < gnentries; ++count) - if ((fscanf(gfp, "%lu %lu\n", - &(gmapdata[count][0]), &(gmapdata[count][1]))) != 2) { - if (ferror(gfp)) - err(EX_OSERR, "%s%s", gmapfile, not); - if (feof(gfp)) - errx(EX_DATAERR, "%s: unexpected end-of-file%s", - gmapfile, not); - errx(EX_DATAERR, "%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; - - error = getvfsbyname("umap", &vfc); - if (error && vfsisloadable("umap")) { - if(vfsload("umap")) - err(1, "vfsload(umap)"); - endvfsent(); - error = getvfsbyname("umap", &vfc); - } - if (error) - errx(1, "umap filesystem is not available"); - - if (mount(vfc.vfc_name, 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(EX_USAGE); -} diff --git a/sbin/mount_umap/sample.group.mapfile b/sbin/mount_umap/sample.group.mapfile deleted file mode 100644 index 69d3d77c63..0000000000 --- a/sbin/mount_umap/sample.group.mapfile +++ /dev/null @@ -1,2 +0,0 @@ -1 -1200 1200 diff --git a/sbin/mount_umap/sample.user.mapfile b/sbin/mount_umap/sample.user.mapfile deleted file mode 100644 index 03c59e9e75..0000000000 --- a/sbin/mount_umap/sample.user.mapfile +++ /dev/null @@ -1,3 +0,0 @@ -2 -5217 5217 -3 3 diff --git a/sbin/mount_umap/umap_manual b/sbin/mount_umap/umap_manual deleted file mode 100644 index 50a8ce5570..0000000000 --- a/sbin/mount_umap/umap_manual +++ /dev/null @@ -1,175 +0,0 @@ - -\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-tree is 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}