Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: Unexpected NFS Effects
Summary: Well, you have to be able to read it to execute it, right?
Message-ID: <12025@bloom-beacon.MIT.EDU>
Date: 15 Jun 89 04:09:40 GMT
References: <403@fang.dsto.oz>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 53

In article <403@fang.dsto.oz> ksh@itd.dsto.oz (Ken Hayman) writes:
>An interesting effect that we found though involves files with mode 711 (I
>suspect the 7 isn't important, but it doesn't work if the files are 700).
>Given a such a file on the NFS mounted file system (ls -lg would show, eg,
>
>-rwx--x--x  1  user   group   10 Jun 14 10:00 file
>
>), it has been found that if I log in a root on a client I can cp the file,
>despite not owning the file (and not being part of "group").
>
>Now I would expect that, if "root" was mapped to "nobody" on the server then I
>should only have execute access to the file, and cp should give "permission
>denied". My question is, is this
>        a) a known bug
>        b) a new bug
>        c) expected behaviour?

It is known behavior, but I am not quite sure it should be classified
as a "bug."

Let's say that you make a file on your local disk mode 711, owned by
root with group operators (or whatever).  This means that the world at
large is allowed to execute the binary, but not to read its contents.
To the kernel, this means that if a request is made to execute this
program, it will be loaded into memory and executed, but if a request
is made to read the contents of the file, it will be denied (unless
the user making the request is root, of course).

Now, take this same file and put it on a remote, secure NFS filesystem.
The kernel gets a request to execute this file, but since the file is
not on a local disk over which the kernel has direct access, it has to
*read* the file using NFS before it can execute it.

Now, NFS can draw no distinction between a root user making a read
request and a kernel, running as root (well, actually, the kernel is
below the level of root, but you get the idea :-), making read
requests, and there is no difference in NFS between a "read for user
viewing" and "read for execution" request.  Therefore, in order for a
kernel to be able to execute a program on an NFS filesystem for which
the user has only execute permissions, the kernel has to be able to
*read* the file using an NFS request.

Because of this necessity, the superuser has the ability to read any
file that has any execute bits set; therefore, you can su to root on
the client and read the file that is mode 711 on the NFS server.

I hope I explained that clearly -- *I* hardly understand that
explanation, and I wrote it :-)

Jonathan Kamens			              USnail:
MIT Project Athena				432 S. Rose Blvd.
jik@Athena.MIT.EDU				Akron, OH  44320
Office: 617-253-4261			      Home: 216-869-6432