# IP Address-Based AFS Access Control for Fun and Profit
You may have heard that the Andrew File System --
[AFS](http://www.openafs.org/) -- allows IP address-based entries for directory
ACLs. The idea is that processes running on a machine with a given IP address
can access protected directories without needing further authentication. You
may have even tried it. If you're like me, you were frustrated. Now I've
discovered the secrets, and I'm going to share them with you. You don't even
have to bribe me.
Why would you want IP-based access? One scenario is that you have files whose
access should be limited to certain machines. Maybe you have software that
should only be run on certain machines because of legal or hardware
limitations. Maybe authentication for certain processes is a drag to work out.
Whatever your reason, this is pretty easy to do after you know the tricks, and
seems to provide a moderate level of security.
Some introductory information and relevant links:
These examples were created under AFS 3.4a and [Sun](http://www.sun.com)'s
[Solaris](http://www.sun.com/software/solaris/) 2.6.
Documentation links
were to Transarc's documentation, until IBM [changed the links and made the
version
3.6](http://www-3.ibm.com/software/stormgmt/afs/manuals/Library/unix/en_US/HTML/AdminRef/auarf002.htm).
Now my documentation links point to the open source version's site,
[OpenAFS](http://www.openafs.org).
Transarc, the original commercial
developer of AFS, is now [IBM](http://www.ibm.com)'s Pittsburgh Lab.
AFS
was first developed at [Carnegie Mellon University](http://www.cmu.edu/) as
part of the [ Andrew Project](http://www.cs.cmu.edu/~AUIS/).
For more
information about AFS, try reading the
[FAQ](http://www.faqs.org/faqs/by-newsgroup/alt/alt.filesystems.afs.html) for
the USENET newsgroup [alt.filesystems.afs](news:alt.filesystems.afs).
All links in this web page should pop up in a single side window, so you won't
have to flip back and forth between pages. I've tried to link every command to
a relevant page, but other references may only be linked at their first
instance.
----
Ok, you'll be dealing with just an IP number for the machine that needs access.
No DNS names: AFS wants just an IP address and none of your carefully
thought-out, clever naming scheme. Yeah, I know -- no fun. You'll have to get
over it. Sorry.
The IP number must be in your AFS
[PTS](http://www.openafs.org/pages/doc/AdminReference/auarf210.htm#HDRPTS_INTRO)
database, just like a user. I'll use your-machine.your-domain.com (1.2.3.4) as
an example.
[Using klog, get an admin token](http://www.openafs.org/pages/doc/AdminReference/auarf200.htm#HDRKLOG) for your AFS cell.
Check to see if 1.2.3.4 is in your PTS database:
bash-2.02$ pts examine 1.2.3.4 pts: User or group doesn't exist so couldn't look up id for 1.2.3.4It's not there. So create it:
bash-2.02$ pts createuser 1.2.3.4 User 1.2.3.4 has id 2147418256The AFS protection database server (PTS) assigns an AFS UID (the number after "User 1.2.3.4 has id ") to the machine. [ Accumulated wisdom recommends](http://www.openafs.org/pages/doc/AdminReference/auarf215.htm#HDRPTS_CREATEUSER) allowing that instead of trying to pick one, so don't use the -id flag unless you're sure know what you're doing and have consulted a [[SysAdmin]] quorum at your site. You can wildcard/subnet these IP-based PTS entries. So you can get PTS ids for IP ranges denoted by, e.g.: 1.2.3.0 1.2.0.0 1.0.0.0 This is supposed to do what you'd think it would: grant privileges to machines within the IP range denoted by the leading non-zero elements. Now you can easily give thousands of people and machines access when you didn't mean to. If you get the idea of wildcarding everything, as in 0.0.0.0, use system:anyuser instead. God knows why you'd want that, and if you're reading this you really ought to know about system:anyuser anyway, but that's how to do it. I don't know what happens if you need to give access to a machine that has a zero as the last tuple of the IP address. Maybe you should get another IP address for that machine. :) OK, now your-machine has an AFS PTS id. But don't put the IP number directly on the ACL. Instead, create an appropriate PTS group and add the machine to it. Don't mix IP and principal entries in the same group; create another group (more on this later). I'll create a PTS group:
bash-2.02$ pts creategroup your-stuff system:administrators group your-stuff has id -1723Again, the number at the end is an ID assigned by AFS. I've chosen here to have group your-stuff owned by system:administrators, but ownership by another group or principal might be appropriate. Joe User -- a cousin of mine :) -- with login joeuser could only create groups starting "joeuser:". Administrators can create groups without this restriction. What does the group your-stuff look like?
bash-2.02$ pts examine your-stuff Name: your-stuff, id: -1723, owner: system:administrators, creator: admin, membership: 0, flags: S-M--, group quota: 0.I'll ignore everything right now except the flags, which are an access control list for the PTS entry. What's above is my local default for groups. The "S" means anyone can run [pts examine](http://www.openafs.org/pages/doc/AdminReference/auarf217.htm#HDRPTS_EXAMINE) on the group. The "M" means anyone can run [pts membership](http://www.openafs.org/pages/doc/AdminReference/auarf222.htm#HDRPTS_MEMBERSHIP) on the group. The flags are SOMAR and affect the operation of the [pts](http://www.openafs.org/pages/doc/AdminReference/auarf210.htm#HDRPTS_INTRO) commands [examine](http://www.openafs.org/pages/doc/AdminReference/auarf217.htm#HDRPTS_EXAMINE), [listowned](http://www.openafs.org/pages/doc/AdminReference/auarf221.htm#HDRPTS_LISTOWNED), [membership](http://www.openafs.org/pages/doc/AdminReference/auarf222.htm#HDRPTS_MEMBERSHIP), [adduser](http://www.openafs.org/pages/doc/AdminReference/auarf211.htm#HDRPTS_ADDUSER), and [removeuser](http://www.openafs.org/pages/doc/AdminReference/auarf223.htm#HDRPTS_REMOVEUSER), respectively. The flags can generally have values of uppercase, lowercase, or hyphen. I won't go into the flags much here, but read the man page, and think carefully about what you want to be seen by whom. For instance, if the group is going to be for machines where users will be allowed to run certain software, you might want to make it easy for folks to discover what those machines are. If you're trying to keep users out, you might want to hide the membership from prying eyes. Pay as much attention to this as you would to any other ACL or permission. By the way, [pts examine](http://www.openafs.org/pages/doc/AdminReference/auarf217.htm#HDRPTS_EXAMINE) works for any entity in the PTS database: groups, principals, and machines. E.g.: bash-2.02$ pts examine 1.2.3.4 Name: 1.2.3.4, id: 2147418256, owner: system:administrators, creator: admin, membership: 0, flags: S----, group quota: 20. The above flags are my current local default for machine entries. Since [ pts examine](http://www.openafs.org/pages/doc/AdminReference/auarf217.htm#HDRPTS_EXAMINE) works for three different types of entries -- machines, principals, and groups -- the man pages get confusing. The flags mean different things depending on what you're examining.
bash-2.02$ pts adduser 1.2.3.4 your-stuffYou'll get back just a prompt. So group your-stuff should now contain
bash-2.02$ pts membership your-stuff Members of your-stuff (id: -1723) are: 1.2.3.4By the way, it's really easy to confuse [pts adduser](http://www.openafs.org/pages/doc/AdminReference/auarf211.htm#HDRPTS_ADDUSER) and [pts createuser](http://www.openafs.org/pages/doc/AdminReference/auarf215.htm#HDRPTS_CREATEUSER). Just like the rest of the AFS command suite, there are too many commands that sound too much alike or don't do exactly what you'd think from the name. Read the man page. Query a local [[SysAdmin]] quorum. You did have an AFS directory you wanted to protect, right? Let's say that directory's permissions currently look like
bash-2.02$ fs listacl /afs/your-domain/your-dir Access list for /afs/your-domain/your-dir is Normal rights: system:administrators rlidwka system:anyuser rlSet directory permissions with [fs setacl](http://www.openafs.org/pages/doc/AdminReference/auarf157.htm#HDRFS_SETACL):
bash-2.02$ fs setacl /afs/your-domain/your-dir your-stuff write"write" is short for all perms except administer. Now [fs listacl](http://www.openafs.org/pages/doc/AdminReference/auarf148.htm#HDRFS_LISTACL) should return something like
bash-2.02$ fs listacl /afs/your-domain/your-dir Access list for /afs/your-domain/your-dir is Normal rights: your-stuff rlidwk system:administrators rlidwka system:anyuser rlSo, you're set, right? Wrong. You put a file in your-dir. You get on other-machine.your-domain.com, and try to look at the file. You can't. That's good. Then you get on your-machine.your-domain.com and try. You still can't look at the file. That's bad. This has always been where I scratched my head and said "I don't get it." But I figured it out. I will now attempt to dispel confusion.
Changes to ACLs for principals are reflected almost right away.
Changes to ACLs for IP entries are NOT.