| Differences Between UNIX and AFS | ||
|---|---|---|
 | Chapter 1. An Introduction to OpenAFS |  |
| Differences Between UNIX and AFS | ||
|---|---|---|
| | Chapter 1. An Introduction to OpenAFS | |
AFS is designed to be similar to the UNIX file system. For instance, many of the basic UNIX file manipulation commands (cp for copy, rm for remove, and so on) are the same in AFS as they are as in UNIX. All of your application programs work as they did before. The following sections describe some of the differences between a standard UNIX file system and AFS.
AFS enables users to share remote files as easily as local files. To access a file on a remote machine in AFS, you simply specify the file's pathname. In contrast, to access a file in a remote machine's UNIX file system, you must log into the remote machine or create a mount point on the local machine that points to a directory in the remote machine's UNIX file system.
AFS users can see and share all the files under the /afs root directory, given the appropriate privileges. An AFS user who has the necessary privileges can access a file in any AFS cell, simply by specifying the file's pathname. File sharing in AFS is not restricted by geographical distances or operating system differences.
To become an authenticated AFS user, you need to provide a password to AFS.
On machines that use an AFS-modified login utility, logging in is a one-step process; your initial login automatically authenticates you with AFS.
On machines that do not use an AFS-modified login utility, you must perform three steps.
Log in to your local machine.
Issue the kinit command to obtain a kerberos Ticket Granting Ticket or TGT. If the kinit is compiled with AFS support, it may automatically get a token for you. However to ensure that you get an afs token, you will need to run a second command.
OpenAFS provides the aklog command to allow you to obtain a token, or AFS service ticket using your kerberos TGT. A kinit with AFS support will run this as part of it's execution, but if you issue the aklog command that will ensure you have an AFS token.
Your system administrator can tell you whether your machine uses an AFS-modified login utility or not. Then see the login instructions in Logging in and Authenticating with AFS.
AFS uses the kerberos authentication protocol, rather than storing passwords in the local password file (/etc/passwd or equivalent). If your machine uses an AFS-modified login utility, you can change your password with a single command. If your machine does not use an AFS-modified login utility, you must issue separate commands to change your AFS and local passwords. See Changing Your Password.
AFS does not rely on the mode bit protections of a standard UNIX system (though its protection system does interact with these mode bits). Instead, AFS uses an access control list (ACL) to control access to each directory and its contents. The following list summarizes the differences between the two methods:
UNIX mode bits specify three types of access permissions: r (read), w (write), and x (execute). An AFS ACL uses seven types of permissions: r (read), l (lookup), i (insert), d (delete), w (write), k (lock), and a (administer). For more information, see The AFS ACL Permissions and How AFS Uses the UNIX Mode Bits.
The three sets of mode bits on each UNIX file or directory enable you to grant permissions to three users or groups of users: the file or directory's owner, the group that owns the file or directory, and all other users. An ACL can accommodate up to about 20 entries, each of which extends certain permissions to a user or group. Unlike standard UNIX, a user can belong to an unlimited number of groups, and groups can be defined by both users and system administrators. See Using Groups.
UNIX mode bits are set individually on each file and directory. An ACL applies to all of the files in a directory. While at first glance the AFS method possibly seems less precise, in actuality (given a proper directory structure) there are no major disadvantages to directory-level protections and they are easier to establish and maintain.
The kinds of failures you experience when a standard UNIX file system goes down are different than when one or more individual AFS file server machines become unavailable. When a standard UNIX file system is inaccessible, the system simply locks up and you can lose changes to any files with which you were working.
When an AFS file server machine becomes inaccessible, you cannot access the files on that machine. If a copy of the file is available from another file server machine, however, you do not necessarily even notice the server outage. This is because AFS gives your cell's system administrators the ability to store copies of popular programs on multiple file servers. The Cache Manager chooses between the copies automatically; when one copy becomes unavailable, the Cache Manager simply chooses another.
If there are no other copies of a file that is stored on an inaccessible server machine, you can usually continue to use the copy stored in your client machine's local AFS cache. However, you cannot save changes to files stored on an inaccessible file server machine until it is accessible again.
The ssh and scp commands enable you to run programs on a remote machine or copy files to/from a remote machine. ssh commands can work seamlessly with AFS, depending on how your administrators have configured them. For the recent versions of OpenSSH, you need to have a kerberos ticket on the machine you are connecting from and support in the ssh client to forward that ticket to the remote machine. The remote machine needs to be configured to use that ticket to obtain a token after it is forwarded.
Most current unix OS's come with a version of OpenSSH that understands the necessary GSSAPI protocol that can use kerberos to forward TGT's, but this ability is generally not enabled by default. In order to configure your ssh client to use this you need to add the following lines to your ~/.ssh/config file.
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPITrustDNS yes
See the ssh_config man page on your system for more details about these configuration options. In particular, you may want to limit them to specific hosts or domains.
If you do not have an ssh client that can do TGT forwarding, when you login into a remote machine, you will have access to native UNIX file system. However, since you are not authenticated to AFS, you can only access the AFS directories that grant access to the system:anyuser group, but you cannot access protected AFS directories. You can enable this access by following the kinit/aklog procedure listed above.
This section summarizes differences in the functionality of some commonly issued UNIX commands.
Only members of the system:administrators group can use this command to turn on the setuid, setgid or sticky mode bits on AFS files. (For more information about this group, see Using the System Groups on ACLs.)
Only members of the system:administrators group can issue this command on AFS files.
Only members of the system:administrators group can issue this command on AFS files and directories.
If the user's AFS tokens are identified by a process authentication group (PAG), the output of this command includes two large numbers. For a description of PAGs, see Authenticating with AFS.
In general, most systems will use a combination of PAM modules to provide both kerberos enabled logins and automatic AFS tokens on login. Often these PAM modules will also be used with screenlockers and graphic logins at the console.
You cannot use this command to create a hard link between files that reside in different AFS directories. You must add the -s option to create a symbolic link instead.
| |  | |
| AFS Security |  | Using OpenAFS with NFS |