Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!genrad!panda!talcott!harvard!seismo!mcvax!ukc!cheviot!ncx From: ncx@cheviot.uucp (Lindsay F. Marshall) Newsgroups: net.unix-wizards Subject: Re: Symbolic user names and RFS Message-ID: <587@cheviot.uucp> Date: Mon, 17-Feb-86 07:16:18 EST Article-I.D.: cheviot.587 Posted: Mon Feb 17 07:16:18 1986 Date-Received: Wed, 19-Feb-86 07:40:31 EST References: <674@oliveb.UUCP> Reply-To: ncx@cheviot.newcastle.ac.uk (Lindsay F. Marshall) Organization: U. of Newcastle upon Tyne, U.K. Lines: 50 Keywords: RFS chown 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 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 : !ukc!cheviot!lindsay -------------------------------------------------------------------------------