Or you can use the `openssl' program.
> 3. user mode mount to another directory (assuming not mounting working
> directory - marked busy, though that might be allowed)
> 4. use another window for local usage.
>
> mountd port has to be redirected
> nfsd port(s) have to be redirected (I think, might not apply to server)
Really, the only critical one if you're worried about people
reading/writing your data is nfsd. mountd is second most important, but
not really if you're using the user-space NFS server.
> biod port(s) have to be redirected
No need for biod.
> lockd port(s) have to be redirected (unless nolocking)
> statd port(s) have to be redirected (not sure)
I'm not sure about statd either. It would be safest to run this over SSL.
> And only a single user per host (not unreasonable).
You could have multiple users per host, with appropriate funky mounts so
each user can only access their own secure mounts. Either mount in a
subdirectory of a user-private directory, or use the Plan9-style
per-user mount trees (experimental patches from Al Viro).
> Would it also work for windows/Macs?
If you put a Linux box in between to implement the SSL part :-)
It's pretty complicated, but then even a simple port-based firewall is
rather complicated with NFS.
Now, if somebody were to fix the portmapper and RPC libraries to use
sensible fixed ports, so we could sensibly firewall RPC services, they
might be tempted to implement automatic SSL tunnelling while they're
there...
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/