Transcript Chapter 18 - Network File Sharing

Network File Sharing
Chapter 18
Chapter Goals
•
•
•
•
•
•
Understand concepts of network file sharing
Understand NFS server setup
Understand NFS client setup
Understand NFS security
Understand NFS mount options
Understand differences and similarities
between AFS and NFS
• Understand basics of Microsoft File Sharing
Network File Sharing
• File servers make files available to other hosts on the
network.
• File service clients obtain file systems from file servers.
• File service peers are (both) servers and clients.
• Network file sharing employs Remote Procedure Calls
(RPC’s).
Network File Sharing
• Network File Systems allow the users files to “migrate” from
workstation to workstation with them.
• Network File Systems simplify life for the user, but generally
make system administration more complicated (due to the
setup costs).
• In Lab 6 we will setup the Sun Network File System (NFS)
services on the lab machines.
• NFS has two components: The server side software, and
the client side software. Each component is actually a suite
of programs which implement the sockets required to
provide network based filesystems.
• NFS is stateless.
Network File Sharing
• Server side:
– Rpcbind (portmap)
– Mountd - respond to mount requests (sometimes called
rpc.mountd).
• Relies on several files
– /etc/dfs/dfstab,
– /etc/exports,
– /etc/netgroup
– nfsd - serves files - actually a call to kernel level code.
– lockd – file locking daemon.
– statd – manages locks for lockd.
– rquotad – manages quotas for exported file systems.
Network File Sharing
• Client Side
– biod - client side caching daemon
– mount must understand the hostname:directory
convention.
– Filesystem entries in /etc/[v]fstab tell the client what
filesystems to mount.
Network File Sharing
wizard# cat /etc/dfs/dfstab
#
place share(1M) commands here for automatic execution
#
on entering init state 3.
#
#
share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource]
#
.e.g,
# share -F nfs -o rw=engineering -d "home dirs" /export/home2
share -F nfs -o rw=boole.cselab.nd.edu:branin.cselab.nd.edu -d "Mail Spool Files"
/var/mail
Network File Sharing
#device
device
#to mount
to fsck
#
/dev/dsk/c0t0d0s1
/dev/dsk/c0t0d0s0
/dev/rdsk/c0t0d0s0
/dev/dsk/c0t0d0s6
/dev/rdsk/c0t0d0s6
/dev/dsk/c0t0d0s7
/dev/rdsk/c0t0d0s7
music:/export/Netwatch/lab -
mount
point
FS
type
fsck
pass
mount
mount
at boot options
/
/usr
/export/home
/usr/lab
swap
ufs
ufs
ufs
nfs
1
1
2
-
no
no
no
yes
yes
rw,soft,intr,bg
Network File Sharing
• The mount command has several extensions for use with
NFS. Mount has to understand timeouts, soft mounts,
background mounts, and the automounter.
– rw/ro - Read/write and read only. NFS file systems that are mounted
read/write can block activity on the client when the server providing
the file system becomes unavailable. See intr and bg below.
– hard/soft - The hard option mounts an NFS file system in such a
way as to ensure that data is written to the remote file system. If the
file server becomes unavailable, a file system mounted with the hard
option will stop all remote file operations until the file server becomes
available again. All file systems mounted with the rw option should
also use the hard option to ensure the integrity of data written to the
file system. The soft option does not provide assurance of data
writes to the remote file system, but does not stop remote file
operations in the case of a file server becoming unavailable. This
option is useful for file systems that are mounted read-only.
Network File Sharing
– suid/nosuid - The nosuid option negates the effect of programs on
the remote file system for which respective setuid bits are set. Setuid
programs run from NFS file systems mounted with the nosuid option
are executed with the normal permissions of the user executing the
program, not those conferred by the setuid bit. This option is used to
increase the security of the client by preventing setuid programs on
remote file systems from being used on the client system.
– bg/fg - This option pair controls how to handle a failed mount of an
NFS file system. Mounts with the bg option are retried in the
background, freeing the shell which issued the mount command. Use
this option when mounting file systems in /etc/vfstab or /etc/fstab to
prevent a workstation from stopping during the boot sequence
because a file server is down.
– intr/nointr - The nointr option prevents program interrupts when
programs cause an NFS operation to occur. This can result in
programs being uninterruptible when an NFS file server becomes
unavailable. The default is to allow interrupts so that programs can
be aborted in the event of server failures.
Network File Sharing
– retry=n - Number of times to retry a failed mount. The default of
10,000 is usually sufficient.
– timeo=n - Time-out value for retrying NFS operations. Increase this
value to permit very slow systems, such as near-line file stores, more
time to complete basic operations.
– retrans=n - Number of retransmissions of a given NFS operation.
The setting depends on the network and type of server being used.
Some networks where packet loss is high benefit from an increase in
the number of retransmissions.
– rsize=n - Read buffer size. Some servers and clients (e.g., those
with slower or less reliable network connections) perform better
when the buffer used for NFS operations is a different size than the
default.
– wsize=n - Write buffer size. Similar to rsize in usage.
Network File Sharing
– proto=? - Controls the network protocol used to transport NFS data.
NFS uses IP datagrams by default. By setting proto=tcp, NFS will
use tcp, thereby improving performance when moving data over wide
area networks and the Internet.
– secure - On Solaris 7 and early versionsof NFS this option enables
NIS+ public key cryptography to be used for NFS authentication and
encrypted communications. This option has been deprecated in favor
of the “sec=?” option below.
– sec=? - New in Solaris 8. This option replaces the “secure” option of
previous versions. It controls the security mode used for NFS.
Options are “sys” for UID & GID based control, “dh” (Diffie-Hellman)
for NIS+ based public key cryptography, “kerb4” for MIT Kerberos
authentication and “none” which provides no authentication and
maps all accesses to “nobody” as described below.
Network File Sharing
– quota/noquota - Setting this option enables disk quota checking via
the rquota service. The rquotad daemon must be running on the
server for this to function. Noquota is the default.
– remount - This option is often used when mounting a file system
manually. It converts a mount point from read-only to read-write
status.
– vers=n - NFS protocol version number (2 or 3). By default, the
mount command will attempt to use the highest version number
protocol available from the server. This option allows the protocol
version to be fixed for use with servers that support only the older
version 2 protocol.
Network File Sharing
– NFS is NOT secure.
• Keep /etc/dfs, /etc/exports locked up (root readable),
• Use Fully Qualified Domain Names for hosts (FQDN).
• Make sure you implement any security patches for
NFS.
• Make sure you get rid of “+” in any automount map
files!
• Monitoring NFS
– The nfsstat command can be used to look at the NFS
performance statistics. The -s flag looks at server statistics,
and the -c flag looks at client side statistics.
Network File Sharing
• Windows uses a different approach to file sharing.
– Server Message Block (SMB) is a proprietary
protocol that was developed to support Windows
networking.
•
•
•
•
•
Port 135
Port 136
Port 137 – the NetBios Name Service
Port 138
Port 139 – The NetBios Session Service
– Now that Microsoft has embraced TCP/IP
networking, Windows is converting to a new
protocol: Common Internet File System (CIFS).
Network File Sharing
• Permissions
– Under NFS, and AFS, the user (or administrator) can assign access
permissions to directories, and to the files within those directories.
– Under Windows, the permissions cover the directory. Files within a
directory inherit the permissions of the directory.
– Shared folder permissions only apply to the folder when it is
accessed via the network. The local permissions pertain when
accessing files locally on the server.
– The default permission under Windows is “Everyone: Full Control” !
• This means that everyone has access to all files in the shared
folder.
Network File Sharing
• Group Permissions
– Domain
• Administrator and Server Operator groups can share
folders on any host in the domain.
• Power Users can share folders on a single host.
– Workgroup
• Administrators and Power Users can share folders.
– Users with the Create Permanent Shared Objects
permission can create shares.
Network File Sharing
• Some folders are shared automatically:
– The share name has a “$” appended to the end.
– These shares are “hidden” shares.
– Automatically shared folders include:
• The root of each volume (C$ D$ E$ …)
• The system root folder (Admin$)
• The location of the printer drivers (Print$)
Network File Sharing
• Sharing setup
– Right click the folder
– Select Sharing
– Fill in the forms
– Network File Sharing is much easier to set up than
NFS/AFS.
– Network File Sharing is much less secure than NFS/AFS.
Network File Sharing
• SAMBA is an SMB/CIFS file sharing daemon that runs on
UNIX hosts.
– Clients make SMB requests on the network
– Samba accepts SMB file requests from clients and uses
UNIX calls to obtain requested file from disks.
– Samba returns SMB file information to the client.
– SAMBA is free.
– TotalNet is another solution which performs the same
function.
• TotalNet is a commercial product.
– “Dave” performs the same function for MacOS. (Free)
• Xinet is a commercial product that performs the same
function.
Network File Sharing
– A common goal for an organization is to provide one
file farm which is accessible from all platforms.
• At Notre Dame we use AFS – it is native to the UNIX
environment, but it works for Windows/MacOS.
– The MacOS and Windows AFS access may be via an
AFS to NFS translator box.
» The client machines run NFS.
» The clients make NFS requests to a translator.
» The translator makes AFS requests to the fileserver.
– NT is supported as a native AFS client. NT does not
require AFS translators.
» NT port uses a memory based filesystem cache
» NT port is not very robust.
» OpenAFS is much better than TransArc’s NT client.
Network File Sharing
• Athena File System (AFS)
– AFS came from the CMU Athena File System.
– AFS is now distributed as a commercial product by TransARC
Corporation (part of IBM).
– OpenAFS is an open source version of AFS built from TransARC
source code.
– ARLA is another open source AFS built from independent code.
– AFS appears most often at Universities.
– AFS was supposed to be a precursor to DFS (Distributed File
System).
– AFS and NFS do the same things, so why chose one over the
other?
Network File Sharing
• NFS
–
–
–
–
–
Distributed with OS
client side cache is optional
clear-text passwords on net
Does not scale well
Uses standard UNIX
permissions
– Not secure
– More reliable than AFS (?)
• AFS
– Add-in product
– client side caching is
standard
– authenticated challenge on
net
– scales well
– Uses Access Control Lists
(ACL’s)
– More secure than NFS
– Less reliable than NFS (?)
Network File Sharing
• NFS
– Low administrative
overhead
– Standard UNIX
backup /restore
– Available for most OS
– Distributed
administration
– Uses standard utilities
• AFS
– High administrative
overhead
– “Enhanced” backup
/restore
– Limited OS availability
– Central administration
– replaces standard
utilities
Network File Sharing
• AFS
– AFS replaces many system library calls with custom versions:
• passwords - are stored in a common (AFS) file.
• ftp, telnet, rlogin, rsh have to be modified to use the new
password utility. (NO LONGER TRUE as of Solaris 2.6 when
using PAM)
• root’s password is held locally in the normal location, so root is
not an authenticated AFS user.
• The filesystem code is altered such that the local cache disk is
checked for files before going to the network.
Network File Sharing
• AFS
– AFS improves system security due to the way it authenticates the
users:
• The UID of the user is ignored by the filesystem. The filesystem
relies on an authentication token instead.
• NFS uses the user id to authenticate file access. The UID can be
changed by a crafty user.
• On standard UFS filesystems, root can read/write every file. NFS
can also allow root read/write.
• Under AFS, root does not have the ability to go read other users
(AFS based) files.
Network File Sharing
• AFS
– When you install AFS, the installation procedure creates some
new directories:
– /usr/afsws - contains the binaries for the AFS suite: fs, tokens, pts
– /usr/vice - contains the AFS administrative files:
• cache files (/usr/vice/cache)
• administrative information about this AFS client
(/usr/vice/etc).
– The package software is also installed. Package is a utility for
updating system files upon reboot.
Network File Sharing
• AFS
• Once all of the binaries are in place, the afs software
creates a cache directory and initializes a series of
files in this directory.
• When the cache scan is complete, the system reboots
so that AFS will start up on the system.
• At reboot, the package utility looks for a configuration
file which tells which files to sync to the master
repository.
– This architecture dependent file tells package which
files need to be updated, what modes to make things,
which entries are regular files, which entries should
force a reboot if they get updated, etc.
Network File Sharing
• AFS
• Once the package command has updated all of the files it looks
to see if any of the updated files had the “reboot” flag set. If so,
the system reboots again.
• This time, the system files should all be up to date.
• Departments can even use their own package run (controlled by
/.package_dept) which updates specific files (sendmail, password
files, message of the day, hosts files, Mentor Graphics links).
– If any of these files have the “reboot” flag set, the system
reboots again.
Summary
• Network File Sharing relies on Remote
Procedure Calls.
• Network File Sharing is convenient for users.
• Network File sharing requires setup by the
sysadmin.
• Network file sharing opens the door to many
security problems.