The Kerberos protocol enables this to happen even while passing information over insecure pathways. Your password is never actually sent across the network, for example. Furthermore, even if your packets are intercepted, those packets still cannot be used to impersonate you.
At MIT, Kerberos is used to authenticate users to AFS, ensuring the security of your data. This, in conjunction with AFS's flexible permissions, provides great power to users. Almost all Athena lockers are located in AFS, including your home directory. This allows you to easily maintain the permissions on files and directories, enabling and disabling access to various users of your choice.
The www directory is primarily intended to be used as a web page. Anything you put in that directory is publicly accessible, and can be accessed with the URLs:
http://web.mit.edu/username/www/ and
http://www.mit.edu/~username/
The Public directory is primarily intended to be used to share files through Athena. Anything you put in that directory is also publicly accessible. To get to someone's Public directory, type:
athena% cd ~username/PublicPublic directories can also be accessed at the URL: http://web.mit.edu/username/Public/
If for some reason your Public or www directories are missing or misconfigured, you can restore them with the following:
athena% cd
athena% mkdir Public
athena% mkdir www
athena% fs setacl -dir Public -acl system:anyuser rl
athena% fs setacl -dir www -acl system:anyuser rlathena% fs listacl directorynameWhen looking at an ACL, you will find up to 7 letters after each entry. These are:
| r | read (allows users to read files) |
| l | list (allows users to list files) |
| i | insert (allows users to add new files) |
| d | delete (allows users to delete files) |
| w | write (allows users to write to files) |
| k | lock (allows users to lock files) |
| a | administer (allows users to administer the ACL of the directory |
Looking at a sample ACL:
This indicates that system:anyuser, a special group that basically includes the entire internet, can list, but not read, the files in your home directory. This is required because in order to access a subdirectory, one needs to be able to list the contents of its parent directory. This also indicates that system:samplegroup, the people on the athena list samplegroup, have full read permissions, and the user sampleuser has full permissions, including setting the permissions of other users or groups.Access list for . is system:anyuser l system:samplegroup rl sampleuser rlidwka
Setting an ACL is similar to listing one. For example:
athena% fs setacl directoryname
system:samplegroup rlidwka
For convenience, you can use read in place of
rl, write in place of rlidwk,
and all in place of rlidwka when setting
ACLs, if you wish. You may also abbreviate listacl as
la, and setacl as sa.
For a small number of of people, you can individually grant them access, by typing
athena% fs setacl dirname username
permissions
for each person you want to grant access to the directory.
For a larger number of people, you can use an Athena managed list, also known as a moira list to control access. To do this, first check and see if the list is an AFS group. To do this, type at the athena prompt:
athena% blanche listname -i
The output should have a line like the following:
asksipb is a maillist and is a group with GID 45072
If it doesn't have a line indicating that it is a group, you can make
it a group, by typing the following command:
athena% blanche listname -G
After it is made into a group, you can grant it access to a particular
directory, in the way mentioned in the previous question, replacing
system:samplegroup with system:listname
One thing to note is that if the mailing list is a mailman list, then, it cannot be made an AFS group. The proper solution would be to ask for a new moira list by going to http://web.mit.edu/accounts and going the "Request a new list" webform.