Namespacing afs and AF_RXRPC

[Eric W. Biederman]

David Howells <dhowells at redhat.com> writes:

> Eric W. Biederman <ebiederm at xmission.com> wrote:
>
>> >  (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.
>
> Yep.  However, afs_test_super() would need to be aware of this, so it needs to
> be listed.
>
>> > 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.
>
> I guess it makes sense to have the net namespace pinned by the superblock.
> However, 'rmmod kafs' would need to find all the net namespaces that have
> state and clean them up.

If the super_blocks are cleaned up.  Nothing extra to do.  At least I
presume so.

>> 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.
>
> Thinking more about it, I'm not sure there's much in common between AF_RXRPC
> and kafs.  Further, the DNS resolver will probably need to move its keyring
> into the net namespace - which means namespacing NFS also.

That is about the only part of NFS that hasn't been namespaced at this
point.

>> 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.
>
> Does it make sense to start /sbin/request_key with the namespace selection
> held by the superblock when doing upcalls on behalf of the filesystem?

Sort of.   The best semantics I have been able to think of is at mount
time find the init process of the current pid namespace.  Magically
in the kernel fork a child of that init process (with a full set of
namespaces and cgroups memberships).

Then have that child wait around for request key upcalls to so it can
run them in the container.

Otherwise we just need to pass enough information to /sbin/request_key
so that it can figure out who is asking and do some userspace magic
to figure out all the details on it's own.

>> Ideally we handle more of it in the kernel but that has proven
>> non-trivial so far.
>
> I don't really want to start putting DNS in the kernel because we then have to
> consider doing secure DNS there too.  Hmmm... I wonder if DNS over rxrpc makes
> sense ;-)

I didn't mean DNS just the logic to figure out which container it should
run in.

>> > 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.
>
> Tricky.  Userspace would have to point at a file and say "use that one's
> namespaces" because a process can theoretically see mounts with different
> backing net namespaces within the same fs namespace.

I was thinking something along the lines of the superblock you are
trying to access isn't visible in this net namespace.  But shrug.

>> 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.
>
> Cute.  Can you give me a pointer to that?

net->proc_net has the base directory.  Which you can use in calls
to proc_create and remove_proc_entry.

fs/proc/base/proc_net.c  has helps like single_open_net and seq_open_net
along with the core of the implementation.

Eric