jerry@oliveb.UUCP (Jerry Aguirre) (02/14/86)
I installed the remote file system (RFS) distributed over the net and
found a big gotcha that other users should be aware of.
If you "ls" files on a remote file system then the symbolic owner and
group displayed will not be correct. Similarly if you "chown" using a
symbolic name that will probably not do what you want it to.
This follows as a natural result of the fact that these programs are
using the password file of the client to translate between symbolic and
numeric user IDs (UID). Unless you have maintained the same UID numbers
on the server systems then the translation will be incorrect.
Our systems all share UIDs for root, man, news, uucp, etc. but a normal
user with accounts on all systems will have little chance of having the
same UID. The most graffic illistration of this is to "ls -l" the
remote file system containing the users' login directories. Normally
the owner and directory name are the same. Under RFS there is a
arbitrary substitution of client names for the server's file owners.
Even worse is to see this and decide to "chown" the files back to what
they should be. The files will now appear correct when listed from the
client but wrong when listed locally on the server.
If you need to chown a remote file then grep the user from the REMOTE
password file and use a numeric chown. Or just use rsh to run the
chown command.
Sollutions:
* One sollution is to have the same password file on all hosts. This
means a massive chown of existing users as well as an ongoing
effort to maintain compatability.
* It is unreasonable (and contrary to the goal of RFS) to modify ls,
chown, find, etc. to deal with the remote UIDs.
* A better alternative would be for the server to map U/GIDs for stat,
chown, etc. It has both password files available for translating
the IDs. The only detail is how to handle names that exist on the
server but not on the client.
Anybody know how this is handled on other networked file systems?
Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|glacier|olhqma}!oliveb!jerrysample@ubc-ean.UUCP (Rick Sample) (02/15/86)
In article <674@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: >Anybody know how this is handled on other networked file systems? The NFS system running on Sun Microsystems machines has the same problems, at least in the versions we are running at UBC. We are in the process of biting the bullet and changing all machines to have the same UID/GID symbolic -> numeric mapping. This is not as onerous as it may at first seems, a few shell scripts can greatly help. I am in the process of doing this in the off hours, at the rate of about one user per day. There are some administrative problems in maintaining a common id space over a number of organizations, though.
smoot@im4u.UUCP (Mitchell) (02/16/86)
It seems that it is *imperative* for security reasons to have the same UID/GID ==> username mapping on any systems which share filesystems. Here at the University of Texas CS Dept, we run mostly 4.2 BSD systems and have been very careful to maintain a uniform user and group mapping system. We handle it by having a master copy of the password and group files maintained on a single system and then distribute particular user accounts to specific machines. i.e. everyone doesn't have a userid on every machine, but a single users userid is the same on every machine he is validated to use. Do do otherwise seems to invite all kinds of chaos. We have developed software to handle this situation when validating new accounts (mostly shell scripts). Anyone who is interested in getting a copy of the stuff we use is more than welcome to it. I am also investigating using the ARPA Internet nameservice to handle these mappings in a more uniform way. I'll let everybody know if I have success in that endeavor. I might add that we do have a number of departments sharing the same ethernet that do not participate in the uniform naming system we use. Of course, if we decide to share files with them using a network file system, that problem will have to be straightened out. We have encouraged other departments to use the same system we have, at least on the systems they own with varying degrees of success.
ncx@cheviot.uucp (Lindsay F. Marshall) (02/17/86)
In article <674@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: >I installed the remote file system (RFS) distributed over the net and >found a big gotcha that other users should be aware of. > .......... > >Anybody know how this is handled on other networked file systems? > One point you have forgotten here is that at the level of the file system you are working with numeric uids NOT names - this is an unfortunate fact of life. Thus, having access to both password files doesnt really help in the slightest. What we do in the Newcastle Connection is to map the pair <system, numeric id> onto a local numeric id (group or user) and to use that for all the remote operations performed. As a result o, files the remote system have ownerships that are sensible for that system, which is important when the systems are autonomous. When a user does an ls -l of a remote system those files that are owned by the uid/gid produced are seen (through manipulation of the "stat" information by the file server) to be owned by the correct username and any others are shown as belonging to a special user (usually called "remote") so as to indicate that "These files exist, but the ownership information would not make sense to you". The reason for this is that the Newcastle Connection ensures that a user's local environment appears to extend to all the remote machines so extraneous information is not allowed to percolate through in this way. It would be possible to do a more complete inverse mapping so that files that were owned by uids for which there was a mapping to the user's local system were seen to belong to the appropriate local users, but there has been no demand for this from users so it has not been fully implemented (Tests showed that it can be SLOOOOOOOOOW, and there are severe problems with inverting many -> one mappings correctly). If you wish to find out who *really* owns a file, the NC provides you with a facility to escape from your local environment and run remotely as though you were a user on the remote machine so you can run "ls -l" in this way and find out. (N.B. this is a special form of remote execution, the normal NC remote execution does not allow you to escape from your local environment. It is also true remote execution, NOT remote demand paging) In general user mapping in UN*X is a mess because of the second-class nature of uids and gids. What we need are full pathnames for everything..... ------------------------------------------------------------------------------ Lindsay F. Marshall, Computing Lab., U of Newcastle upon Tyne, Tyne & Wear, UK ARPA : lindsay%cheviot.newcastle.ac.uk@ucl-cs.arpa JANET : lindsay@uk.ac.newcastle.cheviot UUCP : <UK>!ukc!cheviot!lindsay -------------------------------------------------------------------------------
news@tekcrl.UUCP (Network News daemon) (02/18/86)
In article <759@im4u.UUCP> smoot@im4u.UUCP (Mitchell) writes: >It seems that it is *imperative* for security reasons to have the same >UID/GID ==> username mapping on any systems which share filesystems. > ... >I might add that we do have a number of departments sharing the same >ethernet that do not participate in the uniform naming system we use. Certainly, having a common uid base solves some problems like portability of tar files, etc. But it is not a panacea. We at CRL, in fact do insist on identical uid/username pairs on our two vaxes, but even if I tried to insist on it for the 75 workstations we have here, I'd be silly to expect 100% compliance. And apparently Mr. Mitchell has the same sort of success with the departments not under his control. This problem (plus the fact that I abhor administrative tasks like changing user id numbers at the rate of one-a-day) is why I wrote RFS to do the mapping for you based on existing and easily available information: .rhosts for each user. Certainly, what I did in RFS was not completely satisfactory, otherwise there would be no complaints. I think the best solution suggestion has come from Jerry Aguirre @ Olivetti where he suggests that the server map the user id for system calls like chown, chgrp, etc., because it has the /etc/passwd files for both machines. I would also add that a real good idea would be to do the same for stat, lstat. The problem (with RFS) would then disappear.
dmr@dutoit.UUCP (02/18/86)
In a remote file server scheme, it is an annoying constraint that user ID numbers must be identical on the client's and the server's machine. A proper server should be able to run on machines not under one's administrative control. The Eighth Edition file server handles this by reading map files that specify the translation between the user and group numbers on its own machine and on client machines. When a client requests access, the remote uid and gid are translated to the server's numbers; on the "stat" call the local numbers are translated back to what the client expects. If a client uid or gid cannot be mapped, the server gives "other" access, but it will not create a file with an anonymous uid or gid. It is convenient to fiddle the mapping files to achieve special rules. For example, the mapping for root can be removed to prevent remote super-user access; or between mutually suspicious systems, a very small or empty map can be used to minimize access. It is necessary to keep the mapping files current. We use a daemon that rebuilds them from the join of each server's and client's password file; it runs daily or when requested. Thus we expect that login names, as opposed to numbers, are the administratively controlled identifiers. But this is under control of the people who run the server. In theory, authorizing login names and handing out UID numbers is much the same, but in practice the former is easier. This is true especially when an existing machine joins a consortium; usually there will be few or no name conflicts, but if UIDs have not been controlled they will all need to be changed. Dennis Ritchie
ncx@cheviot.uucp (Lindsay F. Marshall) (02/18/86)
In article <759@im4u.UUCP> smoot@im4u.UUCP writes: >It seems that it is *imperative* for security reasons to have the same >UID/GID ==> username mapping on any systems which share filesystems. Rubbish!!!!! Why on earth should I have to support the same mapping as you? I may wish to map my uid to the username "lindsay" on my machine, but you might want to map it to "Lindsay_Marshall". You may want to map several users from my machine onto a single id on your machine (e.g. "Newcastle"). There is no earthly reason why having a single mapping is any more secure than multiple mappings because in the long run you always have to trust what you are sent by the client and a uniform mapping doesnt stop someone lying. Now, I am not against a single mapping in particular situations (say in a single department) in fact it is probably the most efficient way to do things, but on a large scale it is a disaster. The one most difficult case here is that of the "root" id - it's always 0 and you must *ALWAYS* use some form of authorisation when it is presented to you, if only so you can reject it. Its sometimes better to consider mapping another uid into "root" if someone needs remote superuser access (which you do if you have a single system manager for a set of machines) rather than simply allowing 0 through. >Do do otherwise seems to invite all kinds of chaos. There was a discussion on the net a couple of years ago about the advisability (and possibility) of having a uniform uid allocation scheme throughout an organisation. The general consensus was that it was just impractical given the way that UN*X implements uids. The commonest suggestion was to use employee numbers for the uid value, but these were almost always too large to be usable in most UN*X systems. In fact if you wish to avoid chaos it would seem that keeping users as localised as possible would be the best way - The "Small is Beautiful" approach rather than the "Big Brother". We have tried both on our (small) set of UN*X systems and it really doesnt make much difference for the limited number of users we have, but on a large scale the bureaucracy involved in a global scheme would kill us for sure. ------------------------------------------------------------------------------ Lindsay F. Marshall, Computing Lab., U of Newcastle upon Tyne, Tyne & Wear, UK ARPA : lindsay%cheviot.newcastle.ac.uk@ucl-cs.arpa JANET : lindsay@uk.ac.newcastle.cheviot UUCP : <UK>!ukc!cheviot!lindsay -------------------------------------------------------------------------------
kevin@sun.uucp (Kevin Sheehan) (02/19/86)
<take this all of you and....> In article <1246@ubc-ean.UUCP> sample@ubc-ean.UUCP (Rick Sample) writes: >>Anybody know how this is handled on other networked file systems? regards multiple UID's on multiple systems where symbolic != numeric for their net. >In article <674@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: >The NFS system running on Sun Microsystems machines has the same problems, >at least in the versions we are running at UBC. We are in the process >of biting the bullet and changing all machines to have the same UID/GID >symbolic -> numeric mapping. I dont think it has the same problem (see below), article goes on to describe the perversion involved :-) If you are running NFS, (and are on a sun...) I would assume that you are (capable of) using yellow pages (this is how you do it on other networked file systems...) which provides for centralization (and slave caching) of a number of just such databases - /etc/hosts /etc/passwd /etc/group, and some other things that have proven handy. Sun has >1000 people spread over <favorite deity> knows how many systems, all with unique ID's. I dont know if it (yp) comes with (or near) NFS for you other unfortunates on other machines :-), but I assume with RPC out there it aint real tough. point being, it is easy on the sun (i USE it), and should be next to easy for anyone using NFS/RPC... l & h, kev disclaimer: speak for sun? not even when I am coherent!
jerry@oliveb.UUCP (Jerry Aguirre) (02/20/86)
In article <759@im4u.UUCP> smoot@im4u.UUCP (Mitchell) writes: >It seems that it is *imperative* for security reasons to have the same >UID/GID ==> username mapping on any systems which share filesystems. While, as my original article stated, having different numeric UID/GID can be confusing to the naive, I don't see how it effects security. Remember that, under RFS, your permissions on the remote machine are based on your remote login account and have no direct relationship to your home system UID or user name. More simply, accesses are being performed by a server process not by your process. The server process is operating under the UID of the remote account, not the UID of the client. So, the security is just as good as using rlogin/rsh. (Actually more restricted because it doesn't honor /etc/hosts.equiv.) The only new hole opened is for some unknowing super user to get confused about ownership on remote files and try to "fix" them with chown. Granted that it is a lot cleaner to maintain unique UIDs on all systems, I don't see that it is necessary for RFS. Jerry Aguirre @ Olivetti ATC {hplabs|fortune|idi|ihnp4|tolerant|allegra|glacier|olhqma}!oliveb!jerry
rees@apollo.uucp (Jim Rees) (02/21/86)
In the apollo domain file system, users are identified by unique ID (user UID, not to be confused with unix user ID). The UID is a 64 bit number guaranteed unique across all apollo nodes everywhere. Since no two users ever have the same UID, there is never any conflict, even when you take two networks that were previously disjoint, and conjoin them. Unfortunately, most unix programs want 32 bit user IDs, so we have to have a mapping. But this only affects what you see when you do 'ls -l', it has no affect on access rights checking. What gets sent over the net is the 64 bit unique ID.
chris@umcp-cs.UUCP (Chris Torek) (02/23/86)
In article <2c13e714.1de6@apollo.uucp> rees@apollo.UUCP (Jim Rees) writes: > most unix programs want 32 bit user IDs ... 16. (Actually, it is finally a typedef in 4.3---`uid_t', currently unsigned short.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
jsq@im4u.UUCP (John Quarterman) (02/26/86)
In article <591@cheviot.uucp> ncx@cheviot.newcastle.ac.uk (Lindsay F. Marshall) writes: >In article <759@im4u.UUCP> smoot@im4u.UUCP writes: >>It seems that it is *imperative* for security reasons to have the same >>UID/GID ==> username mapping on any systems which share filesystems. > >Rubbish!!!!! Why on earth should I have to support the same mapping as you? *sigh* Smoot's too polite to followup to these flames. So I'll point out a couple of things overlooked by the flamers: Nobody suggested you should have the same uids as we do. Nobody recommended that even all of our university adopt the CS uid standard, nor have we ever expected them to. The remote filesystem we use at the moment is Sun's NFS, not RFS (neither of them) nor the Newcastle Connection. Jumping to conclusions makes for good flames but not good discussions. -- John Quarterman, UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!im4u!jsq ARPA Internet and CSNET: jsq@im4u.UTEXAS.EDU, jsq@sally.UTEXAS.EDU
wayne@ames-nas.arpa (Wayne Hathaway) (02/26/86)
We (Informatics General Corp, currently undergoing renaming to Sterling Software) have implemented a Newcastle-based remote file system on various flavors of System V for NASA's Numerical Aerodynamic Simulation Project. (I say Newcastle- based because although the ideas are Lindsay's, we have done a lot of rewriting and shoehorning. Lindsay should get the credit for Good Things, Bad Things should be blamed on us.) The code currently connects IRIS workstations, VAXen, and a Cray 2; it will soon be put on two Amdahl mainframes. (And by the by, the underlying networking is provided by our ports of enhanced 4.2BSD code into the various systems, except for the Amdahls where Wollongong's port is currently being used.) We saw from the beginning (thanks, Lindsay) the need for a uid/gid mapping mechanism, and have implemented what we feel to be a flexible, high performance one. We also added the concept of machine-id to provide a single identifier (number) for each machine, so that mappings are truly based on machine and not on something like Internet address (which is in fact the PATH to the machine). In the NASA network, essentially every machine is on both a HYPERchannel and an Ethernet, so the use of machine-id cuts the mapping files in half. About the only difference I see between our mapping scheme and the one in the Eighth Edition is that we have an explicit default mapping defined, so that (for example) a workstation could have unknown uid's map to "guest" while the mass storage system might reject unknown uid's entirely. As they say, for more information contact ... Wayne Hathaway Infor -- oops, Sterling Software (Informatics) 415-964-9900 wayne@ames-nas.arpa
ncx@cheviot.uucp (Lindsay F. Marshall) (02/28/86)
In article <781@im4u.UUCP> jsq@im4u.UUCP (John Quarterman) writes: > >Jumping to conclusions makes for good flames but not good discussions. >-- What conclusions did I jump to??? I wasnt flaming, I was attempting to make a technical point - namely that the statement that a uid scheme such as yours was *imperative* for security was manifestly false. If you have evidence that this is not the case lets see it, otherwise dont try to sidetrack the issue. As far as I have seen none of the points you raised were mentioned by ANY of the posters on this topic - where did they come from??? I repeat again - the only advantage to be gained from having a homogeneous uid (or do you mean symbolic name??) space is administrative. Security is not enhanced at all in fact I think that it may even be decreased, as the space for name/uid guessing is well defined....... ------------------------------------------------------------------------------ Lindsay F. Marshall, Computing Lab., U of Newcastle upon Tyne, Tyne & Wear, UK ARPA : lindsay%cheviot.newcastle.ac.uk@ucl-cs.arpa JANET : lindsay@uk.ac.newcastle.cheviot UUCP : <UK>!ukc!cheviot!lindsay -------------------------------------------------------------------------------
jsq@im4u.UUCP (John Quarterman) (03/02/86)
In article <606@cheviot.uucp> ncx@cheviot.newcastle.ac.uk (Lindsay F. Marshall) writes: >In article <781@im4u.UUCP> jsq@im4u.UUCP (John Quarterman) writes: >> >>Jumping to conclusions makes for good flames but not good discussions. >>-- > >What conclusions did I jump to??? I wasnt flaming, I was attempting to >make a technical point - namely that the statement that a uid scheme >such as yours was *imperative* for security was manifestly false. The conclusions about what our uid scheme *is* which you jumped to. I enumerated the problems in my last article. Stop flaming long enough to go read it. Given Sun's NFS and only Sun's NFS, uniform uids for all hosts using it are indeed bloody well imperative. Once again: we don't use RFS (neither of them), nor the Newcastle Connection, nor V8. I'm quite aware that all of them provide ways of mapping user names into different uids across systems. Sun's NFS *DOES NOT PROVIDE ANY SUCH MECHANISM*! If you want to argue that that proves we should be using one of the others, I'll say you may be right. But stop trying to prove that we should be using a mechanism which doesn't exist in the file system we're using. -- John Quarterman, UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!im4u!jsq ARPA Internet and CSNET: jsq@im4u.UTEXAS.EDU, jsq@sally.UTEXAS.EDU
jack@boring.uucp (Jack Jansen) (03/02/86)
The whole problem is the capability vs. access control list question. While access control lists are usually much easier in use (you never have to specify passwords, etc, except when you log in), there has to be a central authority handing out user names. Capabilities (e.i. passwords) don't need centralized administration, but you have to specify a password on every access. So, in a distributed network, especially one spanning multiple organizations, it is probably better to use capabilities in stead of ACL's. Now, the only problem is to integrate capability-based security mechanisms in unix...... -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
ncx@cheviot.uucp (Lindsay F. Marshall) (03/03/86)
In article <788@im4u.UUCP> jsq@im4u.UUCP (John Quarterman) writes: >Given Sun's NFS and only Sun's NFS, uniform >uids for all hosts using it are indeed bloody well imperative. > We have a misunderstanding here. Given what you say about NFS the original article makes perfect sense, HOWEVER my (very careful) reading of it and your your article did not extract this meaning from it. It was not at all obvious that you were talking about a "feature" of the NFS, but now ots all clear stop the flaming. What is the general feeling about security problems caused by uniform name spaces (if any) - does anyone have any thoughts??? Lindsay
jsq@im4u.UUCP (John Quarterman) (03/05/86)
In article <615@cheviot.uucp> ncx@cheviot.newcastle.ac.uk (Lindsay F. Marshall) writes: >In article <788@im4u.UUCP> jsq@im4u.UUCP (John Quarterman) writes: >>Given Sun's NFS and only Sun's NFS, uniform >>uids for all hosts using it are indeed bloody well imperative. >> > >We have a misunderstanding here. Given what you say about NFS the >original article makes perfect sense, HOWEVER my (very careful) reading >of it and your your article did not extract this meaning from it. It was >not at all obvious that you were talking about a "feature" of the NFS, From my first article, which was meant to clarify precisely that misunderstanding about Smoot's article: > The remote filesystem we use at the moment is Sun's NFS, > not RFS (neither of them) nor the Newcastle Connection. That still looks like plain English to me. -- John Quarterman, UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!im4u!jsq ARPA Internet and CSNET: jsq@im4u.UTEXAS.EDU, jsq@sally.UTEXAS.EDU
wmp@vaxine.UUCP (Wayne Power) (03/14/86)
Dif'rent strokes... We have maintained the same username/uid/gid and group
membership mapping on our four vaxen for two years. Dump and tar tapes can be
read on any machine without a find . -exec chown follow up. The ability to
move users and groups of users around without worrying about the uid stuff
made it well worth our while to whop up the utilities to maintain the password
and group files, add users and do all that good administrative stuff.
Now enter RFS. The server builds tables of all the passwd and group files
from all the machines to which it is providing service as well as every
~user/.rhost it can find on the local machine. If all our users used
~/.rhosts, each instance of the server would be over 400K. We could not use
RFS under these conditions. (Can you say "out of swap space"? :-) By doing
away with these tables, each server is now about 90K. Startup is much faster
as well. I will make these changes available to anyone who wants them after I
run them by toddb.
I can't help but chuckle a bit when I read about the ls -l and chown problems.
Maintaining the uid/gid mapping seems to be the easiest fix. Admittedly, this
can be a real pain in the ass to implement on systems that have lived as
separate entities under different administration for a while. Good luck to
you folk.
If anybody is interested in our passwd/group maintenance stuff, please send me
e-mail.
--wmp Wayne Power
Automatix Inc.
Billerica, MA
vaxine!wmp