User:Rewood/AFS 101

This covers not only what appears in your K: drive for those who have the AFS client on their PCs, but also the permissions when someone ftp's to ftp.ncsu.edu and changes to your afs space, and what you can see from the Sun stations. All three of these are looking at exactly the same space.

First log into your space.

There are lots of methods to due so (Xwin, telnet, ssh, etc) but the simplest => "telnet remote.eos.ncsu.edu" from the dos prompt on a PC, or simply log into a Sun. After you authenticate, the initial directory you begin in will be your home space.

Detect your permissions.

From the prompt type:

fs la

I myself get this return:

system:administrators rlidwka djgreen rlidwka

What this is saying is that the group system:administrators and the user "djgreen" both have 'rlidwka' permissions.

Some of your may see the ids of other faculty whom you've given rights to, some may even have the groups 'system:anyuser' or 'system:authuser'. Its most often these last two that we need to worry about.

There are seven access control rights (ACLs) which can be associated with a user or group. These ACLs are set in each directory. The first four listed apply to the directory; the final three apply to the files in the directory.

administer (a) Ability to change the ACL insert (i) Add new files or sub-directories delete (d) Remove file(s) in directory lookup (l) Permission to examine the ACL and traverse the directory (needed with most other access rights). Permission to look up filenames in a directory. read (r) View the contents of files in the directory write (w) Modify file contents, use "chmod" lock (k) Permission for programs to "flock" files in the directory

Therefore, I have complete rights over my directory (as does the administrators group - those hidden but benevolent gods that restore files you didn't mean to erase - do not inquire nor desire to remove their rights).

Change permissions.

Should I wish to give Margaret the ability to read my directory, I can type the following command:

fs sa . huck rl

If it look at the permissions on the directory again (fs la), I discover the following lines:

system:administrators rlidwka huck rl djgreen rlidwka

Voila, Margaret may now read the files within THAT directory. If I needed to let her read the files in one of my subdirectories as well, then I would need to change to that directory and repeat the process.

I do have the ability to give her access to a subdirectory without giving her access to the directory above it - just give the permission to traverse the directory ('l') in the main directory. That way Margaret can move over the main directory to get to the subdirectory that she has privileges in (Yes, I think that confused even me).

There are short-hand forms instead of the using the letters:

read (rl) read and lookup write (rlidwk) all rights except administer all (rlidwka) all rights none removes all rights

So when I've decided that Margaret no longer needs access, the command:

fs sa . huck none

And poof, all of Margaret's rights dissappear within that directory.

The same can be done for groups as well as individuals. Perhaps you want everyone in the our web team to have access to a directory:

fs sa . ece-web write

will provide us the ability for Margaret and her web team to come in and edit any of that directory's files.

• Side Note* - when you create a directory, it is assigned all of the permissions of the directory in which its created. So any directory the web guys created, they would also have permissions in.

Why this is all important.

The users/groups "system:anyuser" and "system:authuser" are the equivalent of guest accounts. It means that anyone can do whatever those accounts have permissions to do.

This includes web servers - anyone with either of these two user account, even with read only, leaves open the possibility for your files and directories to be read by anyone on the Internet should a webserver be misconfigured to look there. I ran across one today that was and found many of our facultys' files searchable from www.google.com. That webserver has been reconfigured by the department responsible - it was in no way meant to be malicious, but was simply something that was done a long time ago to fix a certain problem and forgotten.

While this can be disconcerting, much of the problem lies with the individuals whom had misconfigured their permissions (hence this guide). So unless there is a specific reason why you have these users present (personal websites - these only need read perms), I would suggest removing them, or at least restricting their permissions where applicable.

Be careful with this one.

For those of you with tens, even hundreds of folders I offer this last command:

find . -type d -exec fs sa {} username permissions >>& /dev/null \;

Its very unwieldy, yes, but it does an excellent job. This will recursively run through your space and set the permissions you designate. Hence,

find . -type d -exec fs sa {} system:anyuser none >>& /dev/null \;

when run from the top of your space, will remove all of "system:anyuser"s privileges in your directories.