But since my plans are just to patch knfsd enough so that it is
usable. I think that I will do something more simplistic. It seems
to me that the easiest way to solve this problem is to do a `dummy'
mount of all of the clients that are found in rmtab. Then if there
is a wild-card entry in the exports files the mount will succeed.
I don't think that there is a race condition on start-up as all of these
`mounts' happen before knfsd is started.
The memory problem is interesting, but I don't think that it is a problem
for most users. It might be a problem with ftp.kernel.org if they where
to let all Linux users make an NSF mount of ftp.kernel.org:/pub/linux.
These are certainly interesting problems.
Allen
>>>Anders Hammarquist said:
> >>>>"G. Allen Morris III" said:
> >> There are several improvements that I need to be made to kexportfs
> >> IMHO.
> >
> >4. There needs to be a `devived export' list. The problem is that if there
> >is a wildcard export like :/. If host `A' mounts / and then
> >`kexportfs -au' is executed followed by a `kexportfs -a' host `A' will
> >get a `Stale file handle' error until `kexport A:/' is executed.
> >Anyone have ideas on the best way to handle this problem?
>
> I've thought some about this, and the neatest (though not neccesarily
> easiest) way I see is to separate the export list into an in-kernel
> cache and an authorative user-mode master list handled by mountd and
> exportfs. What I mean by this is to have the kernel ask mountd about
> any getfh call it receives that is not in the in-kernel cache, and
> reject or allow it based on what mountd responds. In addition to
> avoiding possible race conditions at boot and the like, it would let
> us have very large export lists without using up lots of kernel
> memory. (Credit for some of these ideas is due Steven N. Hirsch
> <shirsch@adelphia.net>)
>
> The other way is to do it the ONC way and accept any good filehandle
> and not bother with the export list. Some might consider the security
> of this approach less than ideal though.
>
---------------------------------
G. Allen Morris III
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html