Le 06/12/2017 à 12:55, Alessandro Selli a écrit :
On Wed, 6 Dec 2017 at 19:03:51 +0800
Yevgeny Kosarzhevsky <phao...@gmail.com> wrote:
On 6 December 2017 at 06:54, Alessandro Selli <alessandrose...@linux.com>
wrote:
Any good reason to refuse NFS in favor of those?
In short: no. Just be aware that NFS is as secure as the trusted networks
it
sits on. Any inside compromised machine can jeopardize the whole
distributed
filesystem.
Ok but this is not about NFS but about any FS that can be accessed over
network.
Not quite. NFS up to and including version 3 is plagued by serious
security weaknesses: lack of transmission security (data is transmitted
unencrypted over the network), lack of integrity (no check on the transmitted
and received data is performed at the session level, and NFS v3 is often run
over UDP) and lack of user authentication/mapping. Most of these security
concerns are addressed by NFSv4, which for the first time supports POSIX
ACLs, RPC over port 2049 alone, authentication and encryption with built-in
integrity checks. However this way you lose the main advantage of old NFS,
that is network efficiency, that was due to the use of UDP as the transmission
protocol.
I am not seeing any danger with NFS especially for /usr or some volatile
data storage used by several systems.
I agree as long as you're using NFSv4 with good cryptography and user
authentication enabled and firewall rules that keep out all machines that
are not of the party. I would only consider NFSv3 for real-time critical uses
when I can have NFS run on a private, dedicated network that was physically
inaccessible by any third party. Or when I can have it run through a tunnel.
NFS is one of Linux base features and I am glad I found understanding of
it's importance from Devuan developers together with mountable /usr over
NFS.
I tend to agree, but I do mind it's complexity and I only deploy it when I
need a permament distributed filesystem between machines in the same
private network. And even then I never use it through WiFi connections. For
all other uses I go for sshfs. My last deployment of NFS was on a DRBL
test system, where I was using NFSv3 from a server that was
delivering it from a physically separated, cabled network. UDP and lack of
cryptography were a boon for the old PentiumIII clients, but I do not
recommend such a layout for anything serious.
As I understood, when someone says about NFS usage, most people get
thinking that the one is going to expose it in internet to any host.
Even in a private environment NFSv3 can lead to data sniffing/spoofing.
Consider how widespread is the use of DSL modems and routers through
which all data exchanged by the local machines goes, as well as the
presence of WiFi APs. Anything that is not secured by good cryptography,
user authentication and solid firewall rules is a security liability in such
an environment.
Last time I set up such an NFS service, I found NFSV4
overcomplicated and with a different paradigm wrt the good old NFS. I
also got the feeling it had been hijacked by MS, and I chose NFSv3, much
simpler and familiar. It is in a network which interconnects privately a
few hosts sitting in the same room. Why would there be any DSL, wifi or
what-else connected to this network? Most servers come with multiple
NICs and connecting them with a private network is easy. The NICs on
servers are automatically reversible (server/host), so that you can
interconnect two servers with just one normal ethernet cable. When there
are more, you need a switch and that's all.
I always configure NFS to use TCP. I don't know what impact it has
on performance. What is essential and tricky is to separate what is
shared between hosts and what isn't. Clearly /run and part of /var/lib
must not be shared. On diskless machines, I mount /run on tmpfs and use
a symlink trickery crossing /run, to unshare some parts of /var/lib,
such as hwclock, ntp, and urandom. And, of course, all syslogs are
forwarded to a remote server.
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
