- applications need to use the same system calls to open/read/write files as if it was on a local system
- conflicts related to parallel acees need to be resolved (two network clients may be trying to modify the same file at the same time)
- state issue (stateful x stateless)
- performance concerns due to network
- security (authentication, privacy, integrity, ...)
- mounting resulting in a file handle (cookie) returned to client which contains fields uniquely identifying
- the file system system,
- the disk,
- the i-node of the exported directory,
- security info
- protocol for file (and directory) access ( read , write, ...)
-
Parts of both server and client are implemented in kernel (no need to configure).
Top layer - System call layer - handles calls like open, read, write, close
VFS (Virtual File System) and v-nodes (either i-node or r-node = remote i-node) for every open file
- Stateful
server keeps track of open files accross the network => complex
after a server crash , the server negotiates with clients to reconcile the state of the connection
clients can maintain more control - Stateless
each request is independent of other requests
nothing lost if server or client crashes
BUT server cannot manage concurency
- firewall compatibility
- lock and mount protocols integrated
- stateful operation
- strong integrated security
- replication and migration support
- unix as well as windows clients
- ACLs
- Unicode names
- good performance even on a low-bandwidth connections
NFS runs on top of Sun's RPC (and XDR - eXternal Data Representation - layer 6 - Presentation in the OSI model)
NFS does packet reassembly and error checking, but doesn't do congestion control (must have for good performance on a large IP network) => TCP
locking (flock, lockf, and fcntl system calls) done separately from NFS by lockd and statd
Part of the core (stateful) protocol in version 4
-
cookie disclosed at the end of successfull mount , persists over reboots
- crashes return to the previous state (unless FS modified through fsck, ... - clients may have to reboot in such a case)
-
up to version 3 inclusive the NFS is an example of everything that has been wrong with unix/linux and security - essentially no concerns when designed ...
- AUTH_NONE
- AUTH_SYS - UNIX-style user and group access control (! client v. server UIDs)
- traditionally used by most sites
- NFS server trusts clients to tell it who they are (what host), what users access the files , ...
- need to enforce passwd file consistency (and more...)
not enough ... we need more robust authentication such as Kerberos where clients are authenticated centrally...
- RPCSEC_GSS - offers integrity and privacy plus strong authentication (through Kerberos ..)
required in v4, optional in v3
semifixes through /etc/exports, + portmap / rpcbind restrictions through /etc/hosts.deny, /etc/hosts.allow
and firewalls
All versions : NFS intended to be security mechanism independent and most servers support multiple "authentication flavors"
Version 4 - mandates support for strong security services and better user authentication
