+== Controlling Who can Access Files ==
+You may be familiar with Unix permissions. Sad to say, but that knowledge is basically useless here. Whereas Unix permissions, are per-file, AFS permissions are controlled by '''Access Control List'''s ('''ACL'''s) on a per-directory basis.
+
+To view the ACL for a given directory (where you have permission to do so), run {{{fs listacl}}} or {{{fs la}}}, for short. For a typical user locker, the ACL in the top level will look like this
+{{{
+user@host:~$ fs la
+Access list for . is
+Normal rights:
+ system:expunge ld
+ system:anyuser l
+ user rlidwka
+}}}
+
+This is a list of users or [#CreatinganAFSGroup AFS groups] and their permissions in this directory (and subdirectories that don't have their own ACL modifications). In AFS there are seven permissions as follows
+
+ ||'''r'''|| read || user or members of group can read files in the directory (i.e. see the contents of files) ||
+ ||'''l'''|| list || user or members of group can list files in the directory (i.e. see the names of files) ||
+ ||'''i'''|| insert || user or members of group can create files (or subdirectories) in the directory ||
+ ||'''d'''|| delete || user or members of group can delete files in the directory ||
+ ||'''w'''|| write || user or members of group can modify files in the directory (i.e. change the contents of files) ||
+ ||'''k'''|| lock || user or members of group can lock files in the directory (you will likely never use this) ||
+ ||'''a'''|| admin || user or members of group can see and change permissions. It does '''not''' affect pre-existing subdirectories.||
+
+To add a user or group to the ACL for a given directory simply run {{{fs setacl}}} or {{{fs sa}}} as follows:
+{{{
+fs sa <directory> <user or group> <permissions>
+}}}
+
+ {{{<directory>}}}::
+ can be an absolute or relative path, usually you will want {{{.}}}
+ {{{<user or group>}}}::
+ can be any user or group. Some you probably want to know: system:anyuser means EVERYONE (the entire AFS-using world plus the entire world wide web), system:expunge is the daemon for MIT's delete/lsdel/undelete utilities to work in a given directory.
+ {{{<permissions>}}}::
+ can be a string of the above letters (in any order) or any of the words `read`, `write`, `all` and `none` which are equivalent to `rl`, `rlidwk`, `rlidwka` and the empty string, respectively
+
+For example, if `user` wants his friends `sipbtest` and `jarandom` to be able to read and write files and anyone to be able to read files in his `awesome_project` directory, he might have a session that looks like this
+
+{{{
+user@host:~$ cd awesome_project/
+user@host:~/awesome_project$ fs sa . system:anyuser read
+user@host:~/awesome_project$ fs sa . jarandom write
+user@host:~/awesome_project$ fs sa . sipbtest write
+user@host:~/awesome_project$ fs la
+Access list for . is
+Normal rights:
+ system:expunge ld
+ system:anyuser rl
+ sipbtest rlidwk
+ jarandom rlidwk
+ user rlidwka
+user@host:~/awesome_project$
+}}}
+
+
+See also: {{{man 1 fs}}}, {{{fs help <command>}}}
+
+== Creating an AFS Group ==
+The "normal" way to make an AFS group would be with a command similar to {{{pts creategroup <your user name>:<group name>}}} and then add people with {{{pts adduser <user> <full group name>}}}(e.g. If Donald Guy wanted to created a group for people to edit his www directory (including `sipbtest` and `jflorey`, he might use the following chain of commands {{{pts creategroup fawkes:www ; pts adduser sipbtest fawkes:www; pts adduser jflorey fawkes:www; fs sa ~/www fawkes:www write}}}
+
+This method will work, but at MIT, it is much more common to use moira lists as a group. To create a new list, use the web interface at https://wserv.mit.edu:444/fcgi-bin/lc? to create a moira list, NOT A MAILMAN LIST and be sure to check the box for "Should this list be an AFS Group?" (to make an already existing moira list into an AFS group simply {{{blanche -G <list>}}}). After the servers update (which may take anywhere between 1 second and 10 minutes depending on the number of similar requests), the AFS group system:<list name> will exist in the athena.mit.edu cell.
+
+This is useful because one often wants the same certain people who can operate on files in a folder to be a mailing list. Thus, for example, it is possible to send mail to gnu@mit.edu and use system:gnu as an AFS group on ACLs. (it is also possible to make moira lists that are AFS groups, but not mailing lists).
+
+see also: {{{man 1 pts}}}
+
+== Controlling Access from the Web ==
+
+If you make a directory listable and readable by system:anyuser then it can be viewed by any user on the web via the urls mentioned [#FromtheWeb above]
+
+Unfortunately, just because you add specific users to an AFS ACL does not mean they can see the folder when the access from the web. IS&T, however, does provide a solution to this. First, make sure that the wanted directory is not readable by system:anyuser. Next {{{fs sa <dir> system:htaccess.mit read }}}. Then create a file named `.htaccess.mit` in that directory. In that file you can do three things,
+
+ * You can require that the user have valid certificates:
+ {{{
+ <limit GET>
+ require valid-user
+ </limit>
+ }}}
+
+ * You can require the reader be (a) specific user(s), for example:
+ {{{
+ <limit GET>
+ require user fawkes jflorey siptest jarandom
+ </limit>
+ }}}
+ * You can require that the reader be a member of one of certain moira groups (notice these are '''moira''' groups, there is no "system:". For example:
+ {{{
+ <limit GET>
+ require group sipb-staff sipb-prospectives
+ </limit>
+ }}}
+
+There after the users should be able to get to the folders at {{{http'''s'''://web.mit.edu/<locker>/<path to folder>}}} if they have certificates and no one should be able to reach it via http. Make sure to add yourself if you are going to be accessing it.
+
+see also: http://web.mit.edu/is/web/reference/web-resources/https.html
+
+
+= Troubleshooting =
+=== I'm trying to access my files, {{{fs la}}} says I should have permissions here, but it still says {{{: Permission denied}}} ===
+There are two likely possibilities. First, its likely that your tokens may have expired. To get new tokens, make sure you have valid kerberos tickets and then run {{{aklog}}}. Another possibility is that you have tokens but not for the correct cell. {{{tokens}}} will tell you what tokens you already have. In all likelihood, if you are reading this, you probably want {{{aklog athena sipb}}}. Finally, a third possibility is that your group membership has changed since you acquired tokens. Try running {{{aklog -force}}}
+
+=== I'd really prefer that not everyone could list my files, how should I stop this? ===
+What you '''don't''' want to do is take away the l permission from {{{system:anyuser}}} because then no one will be able to get to your `Public` or `www` which you probably don't want. All told, there is no way to stop people on Athena from listing your files (unless you keep everything under `Private` or a similarly restricted directory). It is rather trivial to stop web users, however. A solution I recommend, if you have a website in `www`, is to make a page `redirect.html` (or similar) with the contents like:
+{{{
+<html>
+<head>
+ <meta http-equiv="Refresh" content="0; url=http://www.mit.edu/~<lockername>/">
+</head>
+<body>
+ <p>Please go to my <a href="http://www.mit.edu/~<lockername>/">www</a>!</p>
+</body>
+</html>
+}}}
+
+and then doing a {{{ln -s www/redirect.html index.html}}} in the top level of the locker. Alternatively you can link index.html to a blank file in your `Public` or `www` (you can't simply it in the top level because its not readable there, this will result in a 403 Forbidden error).
+
+=== It was around 6am on a Sunday morning and suddenly I couldn't access my files ===
+Yeah, most AFS servers restart weekly at 6 AM on Sunday.
+
+=== It isn't Sunday and I can't get to my files ===
+There may be a non-scheduled AFS outage. Check [http://3down.mit.edu 3down], hopefully it will be back up soon :-(.