Blackbook of AFS

posted onJune 27, 2000

by hitbsecnews

------[
Introduction

AFS is commonly deployed as a distributed filesystem solution in academic
and research environments. This short article serves as an introductory
guide to publicly-accessible resources on AFS. As always, misuse of this
information by the reader is taken at his or her own peril. The current
incarnation of AFS grew out of research conducted with the Andrew FileSystem
at Carnegie-Mellon University, also home of the CODA distributed fs research
(http://www.coda.cs.cmu.edu/). AFS is now a commercial product, supported
and sold by the Transarc Corporation (www.transarc.com).

----[
Conventions

Resources
on AFS listed in this document will take the form of '/afs/cell name'.
As you will discover, certain hosts are only accessible from a gateway
immediately associated with the cell. For example, the node net.mit.edu
can only be reached from the outside (ie. using methods other than a local
fs mount) through the web.mit.edu AFS gateway. Where appropriate, these
access restrictions are noted.

----[
Basics

Terminology

cell : Multiple hosts within the same domain sharing a single fs image.

-
local cell : Describes a cell within the local domain.

- foreign cell : All cells not within the local domain.

- cell name : Usually a derivation of the FQDN.

node
: Generic term for any host on the network.

ACL
: Access Control List - who gets what, and how.

Technical

Access permissions of files and directories on an AFS cell are handled
independently of the underlying operating system permissions. Traditional
Unix fs permission bits are divided into read, write, and execute. The
AFS ACL groupings build on this concept and add extensions suitable for
distributed file-sharing.

Below
is a basic introduction to concepts and commands used to manage AFS; by
no means a complete treatment of the subject. See tutorials at

http://www.alw.nih.gov/Docs/AFS/AFS_toc.html and

http://www.slac.stanford.edu/comp/unix/afs/users-guide/afs-frames.htm
for more information.

ACL
bits

r : read : view directory and file contents

l : lookup : searching of a directory for filenames (recursive find)

i : insert : create a new directory or file

d : delete : remove a file or subdirectory

w
: write : modification of file contents

k : lock : owner's processes allowed to flock() in this dir

a : administer : user permitted to modify ACL for this resource

Commands
for ACL listing and modification

fs:
listacl (alias: la) : list access control list setacl
(alias: sa) .... set access control list

ex.
setacl secret.doc jsbach lidrw

pts:

Invoked as 'pts option' on the command-line. Manages protection groups,
which permit a smaller group of users to access resources owned by another
user.

options:
adduser -user user1 user2... -group : .... adds user(s)
to an existing protection group

removeuser
-user user1 user2... -group : .... removes user(s)
from a protection group

creategroup
: .... create a protection group

examine
. volume name of specified resource at

membership
-name (alternatively :) .... list protection
group membership for user

Protocol
information

AFS is implemented over wide-area TCP/IP networks, optionally authenticating
users with a modified Kerberos implementation. Client nodes utilize a
cache manager, which stores frequently-accessed data on a local disk for
faster retrieval.

Taken
from an unknown cell's /etc/service, the ports and protocols that make
AFS work its magic:

afs3-fileserver 7000/udp # file server itself

afs3-callback
7001/udp # callbacks to cache managers afs3-prserver 7002/udp # users
& groups database

afs3-vlserver
7003/udp # volume location database

afs3-kaserver
7004/udp # AFS/Kerberos authentication service afs3-volser 7005/udp #
volume management server

afs3-errors
7006/udp # error interpretation service

afs3-bos
7007/udp # basic overseer process

afs3-update
7008/udp # server-to-server updater

afs3-rmtsys
7009/udp # remote cache manager service

Gateways

Legitimate access to AFS is quite easy to obtain. Any alumnus of an institution
where AFS is widely deployed (MIT, CMU, Stanford, etc.) usually has an
account on a connected node. Additionally, it is not uncommon for admins
to grant research accounts on university systems to friends outside.

For
those without friends and we, the unwashed masses, there are gateways
which allow access to AFS through other services. In the early 1990's,
these were commonly found on institution FTP and Gopher sites. Today,
most gateways provide proxied access to AFS through the web. Transarc
provides the WebSecure product which is the most commonly used gateway
software.

AFS->web
gateway discovery is a matter of blind luck, although with the assistance
of a search engine, it is possible to select possible candidates. Two
commonly-used gateways are:

web.mit.edu
and www.transarc.com

The
MIT gateway is more controlled than the Transarc's. Of the 74 active cells discovered, MIT permits only 12:

andrew.cmu.edu

athena.mit.edu

cmu.edu

cs.cmu.edu

ece.cmu.edu

iastate.edu

ir.stanford.edu

net.mit.edu

northstar.dartmouth.edu

sipb.mit.edu

transarc.com
umich.edu

Some
cells local to mit.edu are accessible through the gateway with aliases,
namely: athena, dev, net, and sipb. These aliases and restricted-access
nodes are not enumerated.