From: Anders Kaseorg
-
-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 +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 +user@host:~$ fs listacl Access list for . is Normal rights: system:expunge ld @@ -152,7 +152,7 @@ This is a list of users or AFS groups and thei 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> [<user or group> <permissions>]* +fs setacl -dir <directory> [<directory>]* -acl <user or group> <permissions> [<user or group> <permissions>]*
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$ #alternatively: fs sa . system:anyuser read jarandom write sipbtest write -user@host:~/awesome_project$ fs la +user@host:~/awesome_project$ fs setacl -dir . -acl system:anyuser read +user@host:~/awesome_project$ fs setacl -dir . -acl jarandom write +user@host:~/awesome_project$ fs setacl -dir . -acl sipbtest write +user@host:~/awesome_project$ #alternatively: fs setacl -dir . -acl system:anyuser read jarandom write sipbtest write +user@host:~/awesome_project$ fs listacl Access list for . is Normal rights: system:expunge ld @@ -183,13 +183,13 @@ user@host:~/awesome_project$
See also: man 1 fs, fs help <command>, man fs_listacl. -There is also such thing as negative permissions to deny rights to certain members of a larger group to which positive permissions are granted. In the words of the fs_setacl manpage, however,
Setting negative permissions is generally unnecessary and not recommended. Simply omitting a user or group from the "Normal rights" section of the ACL is normally adequate to prevent access. In particular, note that it is futile to deny permissions that are granted to members of the system:anyuser group on the same ACL; the user needs only to issue the unlog command to receive the denied permissions.For an example of negative permissions used on Athena run fs la /afs/athena.mit.edu/contrib/games/. +There is also such thing as negative permissions to deny rights to certain members of a larger group to which positive permissions are granted. In the words of the fs_setacl manpage, however,
Setting negative permissions is generally unnecessary and not recommended. Simply omitting a user or group from the "Normal rights" section of the ACL is normally adequate to prevent access. In particular, note that it is futile to deny permissions that are granted to members of the system:anyuser group on the same ACL; the user needs only to issue the unlog command to receive the denied permissions.For an example of negative permissions used on Athena run fs listacl /afs/athena.mit.edu/contrib/games/.
-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 /mit/fawkes/www fawkes:www write +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 setacl -dir /mit/fawkes/www -acl fawkes:www write
You can see general information about a group by running pts examine <group> and see the membership of a group by running pts membership <group>. In the above example: @@ -197,7 +197,7 @@ You can see general information about a group by running pts examine <gro fawkes@dr-wily:~$ pts examine fawkes:www Name: fawkes:www, id: -33555072, owner: fawkes, creator: fawkes, membership: 2, flags: S-M--, group quota: 0. -fawkes@dr-wily:~$ pts mem fawkes:www +fawkes@dr-wily:~$ pts membership fawkes:www Members of fawkes:www (id: -33555072) are: jflorey sipbtest @@ -234,7 +234,7 @@ Unfortunately, adding specific users to an AFS ACL does not mean they can see th
Note that you cannot mix users and groups in the same directory
. -Finally fs sa <dir> system:htaccess.mit read .
+Finally fs setacl -dir <dir> -acl system:htaccess.mit read .
Thereafter, the users should be able to get to the folders at https://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. @@ -243,7 +243,7 @@ Thereafter, the users should be able to get to the folders at https:/ see also: http://ist.mit.edu/services/web/reference/web-resources/httpsThere are two likely possibilities. First, its likely that your tokens may have expired. You can check this by running tokens. If they are, in fact, expired (or missing) get new tokens as follows: first, 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 @@ -319,7 +319,7 @@ While it is easily possible to make an AFS group for yourself, it is harder to g
Figure out the volume name of the locker. One way to do this is to run fs lq . in the directory and look in the left column. Once you have the volume name, run vos examine <volume name>. This will tell you information such as what server it is located on, its ID numbers, when it was last accessed, when it was last backed up, etc. For example: +
Figure out the volume name of the locker. One way to do this is to run fs listquota . in the directory and look in the left column. Once you have the volume name, run vos examine <volume name>. This will tell you information such as what server it is located on, its ID numbers, when it was last accessed, when it was last backed up, etc. For example:
$ vos examine user.sipbtest user.sipbtest 537058147 RW 69785 K On-line diff --git a/doc/zcrypt.mdwn b/doc/zcrypt.mdwn index 4b744e4..ee75aa9 100644 --- a/doc/zcrypt.mdwn +++ b/doc/zcrypt.mdwn @@ -6,9 +6,13 @@ Zephyr at MIT doesn't support* limiting who can sub to a zephyr class, so if you The main requirement for a `zcrypt`ed zephyr class is to distribute a key to all the intended users of the class. Typically, this is done by storing the key in AFS. You can set that up like this: - mkdir -p ~/Public/zcrypt/label/ # Pick an arbitrary label for your class. - fs sa ~/Public/zcrypt/label/ system:anyuser none # Keep randoms from reading your key - fs sa ~/Public/zcrypt/label/ system:groupname read # Allow an appropriate user/group to read the key + # Pick an arbitrary label for your class. + mkdir -p ~/Public/zcrypt/label/ + # Keep randoms from reading your key + fs setacl -dir ~/Public/zcrypt/label/ -acl system:anyuser none + # Allow an appropriate user/group to read the key + fs setacl -dir ~/Public/zcrypt/label/ -acl system:groupname read + # Generate a 126-byte key with no NUL or newline bytes tr -d '\000\n' < /dev/urandom | head -c 126 > ~/Public/zcrypt/label/key.zcrypt The first three lines create a directory to store the key, and set the permissions properly. You should replace `label` with an appropriate name; you may want to use something besides the class name in order to help keep the class name private. Subbing to the class will disclose traffic patterns and instances used, so you may want to use the traditional "secret class" (keeping the name secret) as a first line of defense, in addition to `zcrypt`.