Hello. I am writing to 9fans to solicit discussion (and hopefully consensus)
about a proposed patch to import(4) to match the options that currently exist
in exportfs(4). I have submitted a patch(1) to sources to be found in
sources/patch/importz. The readme and manpages for that patch also explain this
issue but based on my discussions with other users in IRC, I would like to
submit the topic for community analysis. I am sorry for any inaccuracies,
please correct any mistakes. I appreciate all the discussion I have had with
others already.
Summary: currently, the exportfs(4) options -a and -r or -S are incompatible
when exportfs is being used as a listener. I propose a simple patch to import
to allow import to correctly mount exportfs(4) services that are using these
flags. A new flag -z tells import to skip the same part of the protocol (tree
request) that exportfs skips when using the -r or -S flags.
Example:
aux/listen1 tcp!*!9876 /bin/exportfs -a -r /usr/me/authedexport
Translated to english, this command says: listen on port 9876, authenticate
clients, and then serve this directory. This is a sensible usage of exportfs.
However, neither current import(4) or srv(4) and mount is able to connect to an
exportfs run with these options. It creates a protocol variant which is
currently unsupported. The same issue exists if you substitute the -S flag
(exportfs of a service mount usually from /srv).
The proposed patch allows you to use this command to mount the above export:
import -z tcp!server!9876 somefiles /n/authedimport
(because the string for the remote tree is not sent to the server under this
protocol variant, somefiles can be any random string.)
The implementation of the flag is completely trivial, simply wrapping the tree
request code in an if block. It changes no existing behavior of either exportfs
or import. No new bugs or incompatibilities in existing scripts and configs are
created. The purpose is simply to make import conform to the options which
already exist in exportfs. I believe that making exportfs and import
symmetrical in terms of supported options and modes is fundamentally sound.
At the moment, exportfs is happy to listen with -a -r but nothing can mount it.
I see this patch as a bugfix for this poor interaction of flags.
In discussing this issue and patch with others, several potential issues and
objections have been raised. I would like to discuss them to try to clarify
possible objections and misunderstandings. A list of objections and responses:
1. This creates additional complexity.
I do not believe so. The complexity is created by the already existing flags to
exportfs and their interactions. The -z flag to import exists to match the
existing behavior of exportfs and allow to use the existing exportfs options to
function in combination without producing non-mountable exports,
2. There is no purpose to this, because a standard exportfs -a of the full
root allows the client to request whatever subroot it wants, or mount and then
mount any /srv it wants.
I understand this point, but I think there are several responses. The first is
that fixing broken interactions of seemingly sensible flags is a good thing to
do no matter what. You can cp a file by cat file newfile but that doesnt mean
that a bug in cp isnt worth fixing, just because you can perform the operation
another way. The second is that you could make the same argument for an http
server: Why does an http server need to be able to serve a specific
subdirectory? You can always serve the whole root of the tree and the client
can choose to look in the www subdirectory. - in other words, choosing a
specific portion of namespace or a specific /srv is a sensible thing to do to
restrict access. As a user, saying I only want to export this much is
desirable.
3. The -P patternfiles let you control that also. Yes, but the patternfile
mechanism is definitely more complex, and when you have a simple flag like -r
to select a given root, why impose the necessity of creating a patternfile
rather than using the -r flag which already exists? To some extent this
argument and the previous are more arguments about the design of exportfs. My
belief is that whatever exportfs does, import needs to support. There are many
possible ways to have the protocols work - but I am proposing a simple change
to fix a currently existing issue, the question of whether or not the -r or -S
flags to exportfs are superfluous is a design issue. Those flags exist, and I
believe it makes sense for import(4) to support the same behavior those flags
create.
Also, my fundamental concern is making exportfs -a -S mountable by something,
somehow - the exact mechanism isnt the most important thing. I believe a tiny
patch to import makes the most sense in terms of minimalism and simplicity, but
you could deal with this issue in many ways - make exportfs and import smarter
about tree negotiation, let