Network File Sharing

1. Network File Sharing Chapter 18

2. 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 Chapter Goals

3. 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

4. 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

5. 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

6. 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

7. Network File Sharing

8. Network File Sharing

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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. Network File Sharing

30. 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. Summary