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:
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/Public
Public 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% mkdir Public
athena% mkdir www
athena% fs setacl -dir Public -acl system:anyuser rl
athena% fs setacl -dir www -acl system:anyuser rl
If you simply wish to find out the ACL for the current directory, you may omit directoryname.
athena% fs listacl directoryname
When 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:
This gives full permissions to the samplegroup group for directoryname, though does not refer to subdirectories of that directory.
athena% fs setacl directoryname system:samplegroup rlidwka
For convenience, you can use
read in place of
write in place of
all in place of
rlidwka when setting
ACLs, if you wish. You may also abbreviate
For a small number of of people, you can individually grant them access, by typing
for each person you want to grant access to the directory.
athena% fs setacl dirname username permissions
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:
The output should have a line like the following:
athena% blanche listname -i
If it doesn't have a line indicating that it is a group, you can make it a group, by typing the following command:
asksipb is a maillist and is a group with GID 45072
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
athena% blanche listname -G
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.