Re: [9fans] the import/exportfs protocol and a proposed import -z flag

Re: [9fans] the import/exportfs protocol and a proposed import -z flag

[mycroftiv]

Charles Forsyth <charles.forsyth@gmail.com> wrote:

> As you'll have noticed, it isn't a great protocol as it stands. I don't
> think your option makes it worse.

Thanks for your perspective.  I'm glad that my long-winded explanation
didn't obscure the basic logic too much.  It makes sense for import to
be able to dial and attach to an exportfs -a -r listener, and right
now it can't.  You mentioned someone was already carrying an
equivalent patch with the -m flag, and another user I spoke with
mentioned they had written their own exportfs server which addressed
this on the exportfs end.  Since a few different users have run into
this and wanted to use the "authentication, no tree request" protocol
variant, it would be good I think if all users could connect to that
type of server using a standardized method.  If the -m flag already
has some existing users, it might be a better choice than -z for this
option.


> Note that in your example
>         import -z tcp!server!9876 somefiles /n/authedimport
> with the existing import you don't need to specify the (now unused)
> somefiles. If I write {import system /net} it sends "/net" as the tree by
> default.
> I think all you'd need to do to make the option tidier is to reject the
> case argc == 3 in the relevant switch if the option is set. Then you could
> write
> (changing the option letter):
>       import -m tcp!server!9876 /n/authedimport
> which reads as import by mounting the 9P service on the given connection on
> the given mount point. It's otherwise a little strange to have an
> argument (your "somefiles") that's completely ignored.

I totally agree.  In fact I was unclear about this.  The way I wrote
it made it seem as if sending the unused parameter was mandatory - but
in fact, import already has this logic:


		switch(argc) {
		case 2:
			mntpt = argv[1];
			break;
		case 3:
			mntpt = argv[2];

So it is already the case that

	import -m tcp!server!9876 /n/authedimport

would do the mount at the specified point.  I wrote out the version
with the unnecessary parameter to try to clarify what what -z was
doing, but in practice you just write it exactly as you described.
Maybe the argc==3 case should be rejected just as a reminder to the
user that the tree request will not be sent.

Ben Kidwell
-mycroftiv

Re: [9fans] the import/exportfs protocol and a proposed import -z flag

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

On 27 February 2013 08:24, <mycroftiv@sphericalharmony.com> wrote:

> I hope this post leads to constructive discussion of the import/exportfs
> protocol.


As you'll have noticed, it isn't a great protocol as it stands. I don't
think your option makes it worse.
Thanks for the detailed discussion. I think at least one existing system
already does what you say, using the -m option ([just] mount, skipping the
tree spec),
and if you were to use that in a patch to sources, then eventually that
private change could be eliminated.

Note that in your example

         import -z tcp!server!9876 somefiles /n/authedimport

with the existing import you don't need to specify the (now unused)
somefiles. If I write {import system /net} it sends "/net" as the tree by
default.
I think all you'd need to do to make the option tidier is to reject the
case argc == 3 in the relevant switch if the option is set. Then you could
write
(changing the option letter):
        import -m tcp!server!9876 /n/authedimport
which reads as import by mounting the 9P service on the given connection on
the given mount point. It's otherwise a little strange to have an
argument (your "somefiles") that's completely ignored.

As you say, this could also reasonably be an option to srv to authenticate
its connection to a remote exportfs, but the fewer commands that know
this particular protocol, the better, and both import and exportfs already
do that.

[-- Attachment #2: Type: text/html, Size: 2615 bytes --]

[9fans] the import/exportfs protocol and a proposed import -z flag

[mycroftiv]

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 srv know how to talk the "-a -S/r" protocol, etc. The issue of the "unmountable protocol" is something that could be solved in many ways, but I believe it definitely should be solved in some way. The proposed patch adding -z flag to import is trivial and i believe trivially "verifiable' in the sense that it is guaranteed to allow you to mount those exports and not introduce any new buggy behaviors.

4. "The -r and -S options are really just for -B mode" I haven't actually heard anyone say this, but I can imagine it as a potential response. To some extent the previouis answers respond to this also, but another response is simply a user perspective: I find that doing listeners with -a -r and -a -S is something that is useful to me. It seems like the most direct way to share a specific piece of namespace or a specific service with auth, and that is a sensible thing to do. Perhaps the -r and -S flags were added with -B mode in mind and that has been the primary historical use, but when you translate the meaning of the commands into english - "do an authenticated export of this service or this part of namespace" - it seems to me like a simple and sensible use of the commands and flags.

5. "Exportfs isn't intended to be used in this way" I don't think this is true. Exportfs is intended as a general mechanism to share namespace of any kind. It is a core system utility. The essence of Plan 9 is network transparent namespaces. The flexibility of being able to share namespace across a network however you want is very important to Plan 9, and so making exportfs and import work together in all situations and with all options is a sensible goal. I think that exportfs -a -r and -a -S listeners are a useful tool for both private and public plan 9 networks.

6. "OK, but patching import isn't the right solution, the right solution is..." maybe you are right. I don't have strong opinions about whether or not a new flag is better or worse than trying to extend the import/export protocol to be smarter in its negotiation or whether some other solution is preferable. I do think that the proposed patch is trivially "correct" in fixing the problem, non-disruptive to all existing users, and based on a sensible principle of symmetry between exportfs and import. Even if you think a better long term solution involves changing the export/import protocol or even unifying srv and import as a single tool to handle all kinds of 9p connections and authentications, perhaps you might view import -z as a decent temporary solution.

7. "Why is this important? This has never affected me, can't it just be ignored?" I agree that this is an issue which is only like to come up if you are creating "on-demand" service listeners with aux/listen1 for various purposes, but that is basic functionality for some grids of machines. 9p is the heart of plan 9, and the tools which work with 9p services should let you serve and mount using the options of your choice. Making exportfs and import match cleanly is just like making the electrical plugs match electrical pluckets - square pegs, square holes, round pegs, round holes.

8. "You submitted the patch already, what is the purpose of this huge 9fans post?" The reason for soliciting community discussion is my practical awareness that Plan 9 is now being distributed in several forms, some consiered "forks" and some "not-fork variants". I mentioned that I think the tools for creating and importing 9p services over the network are foundational, so to me the interaction of import and exportfs and how the options work on each side is something that all the plan 9 developers (and users) should have consensus on.

I also hope that the intent of this post - constructive discussion and consensus about how these tools should work - is clear.

I have had long discussions with many people who are more expert in plan 9 use and development than I am, and I have not succeeded in achieving consensus about my perspective and proposal. I want to have constructive discussion about an issue i think is important because it affects how all Plan 9 systems which make use of exportfs/import communicate. I hope this post leads to constructive discussion of the import/exportfs protocol.

Ben Kidwell
-mycroftiv