Namespacing afs and AF_RXRPC

Eric W. Biederman ebiederm at xmission.com
Thu Apr 6 10:57:19 PDT 2017


David Howells <dhowells at redhat.com> writes:

> Hi Eric, Al,
>
> I'm thinking about how to namespace the in-kernel AFS client and AF_RXRPC.
> It's not completely trivial, however.
>
> For the AFS client, I think the way to namespace it is:
>
>  (1) Manual mounts are in the fs and net namespace of the parent
>  process.

So from the perspective of filesystem there is not a fs or a mount
namespace.  There are just superblocks.

>  (2) Automounts inherit the parent vfsmount's net namespace.  I'm not sure
>      about fs namespace.

Yes.  The automounts need to inherit it all from the parent filesystem's
superblock.

>  (3) Mounts in the same net namespace can share:
>
> 	- A cache manager
> 	- Cell list
> 	- DNS lookup cache
>
>      Mounts in different net namespaces would require a different cache
>      manager running on a different port.
>
>  (4) Two mounts with different net namespaces accessing the same volume *have*
>      to have different superblocks - even if they're in the same fs namespace
>      - because we don't want to end up playing callback ping pong between
>      sockets.

And how would you tell if they were mounts of the same filesystem.  The
same IP address in different network namespaces can route to
different filesystems.

> I'm not sure how to link AFS's information to the net namespace.  Would I have
> to add a pointer to struct net to say, a struct netns_afs?  It might be
> possible to combine this with AF_RXRPC and have a struct netns_rxrpc, but I'm
> unsure as to whether that makes sense.

I would have a struct net pointer in the superblock.

Past that something to embed in struct net (statically or dynamically
with the net_generic infrastructure) either just a netns_rxrpc structure
of if it comes out cleaner both a netns_rxrpc structure and a netns_afs
structure.

> Also, this brings into question namespacing key lookups as the DNS service in
> the kernel is accessed through request_key() - but they need to be done in the
> appropriate net namespace.

Yes.  We don't have a particularly good answer for that but it is on the
list of things that would be nice to fix so you can expect coopearation.

Worst case /sbin/request_key needs to have enough information to know
requests are coming from different network namespaces and to take the
appropriate action.

Ideally we handle more of it in the kernel but that has proven
non-trivial so far.

> For AF_RXRPC, new sockets would pick up the parent's net namespace - but
> there's a potential problem: AF_RXRPC will be used for tools that manage the
> AFS filesystem.  Some commands can be implemented by asking the kernel to do
> operations on our behalf, but not necessary all.  However, we might be in a
> separate namespace to the AFS mount that we're looking at, so if we open an
> AF_RXRPC socket, it may be directed differently than operations we do on the
> filesystem.
>
> Maybe that's just something to mark as 'don't do that then'.  If you set up
> your container that way, you're asking for trouble for the occupants.

Very much so.  I would try and return an error in that case.  But I
don't know how doable that is to implement.

> Anyway, there's a variety of global information in AF_RXRPC that would need
> moving into a namespace:
>
>     - Peer records.
>     - Rx epoch (appears in packet headers).
>     - Service connection list.
>     - Connection list for procfs.
>     - Call list for procfs.
>     - Local endpoints list.
>
> I think /proc/net/rxrpc_* would have to return just what's in the caller's net
> namespace - which might mean you won't see things your filesystem has access
> to because that's in a different namespace.

And we have network namespace infrastructure to make those kinds of
things per network namespace already built and debugged.  So you should
just be able to use that.

> I think the client connection lists have to stay global because (a) we
> maintain a global IDR of client connections to facilitate fast lookup in the
> UDP data_ready handler; (b) this manages the limitation on the number of
> client connections.
>
> David



More information about the linux-afs mailing list