Posts Tagged ‘afs’

The AFS saga continues

Friday, December 14th, 2007

In the previous post, I mentioned that AFS denies access to your files when you do not have a token. This is still true, but apparently, you are able to launch both at and cron jobs using keytabs. This is a file, residing outside of the AFS realm, containing the password in some processed form (so the password is not available in clear text). Keytabs are created by the system administrator. More information is available here (ELIS internal use only). This seems like the best way forward, and also the most secure approach.

There is, hoewever, a far less secure alternative. You can provide your password in a file, or interactively, to the kinit process which will then obtain a token on behalf of the application you wish to execute, by doing

kinit --password-file=filename application

Saving the password in a file (especially outside of AFS) seems like a major security issue, but that’s probably me.

Tags: , , ,
Posted in Uncategorized | 1 Comment »

AFS does not like screen

Thursday, December 13th, 2007

People at our department are often running jobs that take multiple days to complete. A good way to keep a job going is to use the screen tool. This allows one to keep running a shell even when not connected to the machine for a while, and to reconnect to that session when you login on the machine once more. Simple, lean and mean.

Suppose you wish to run a job, and save its output to a file that resides on your home directory, which is, incidentally, and AFS mount. You log in, get a token (as per the manual method described here, fire up screen, start your job, leave screen (using the nice ctrl-a-d keystroke), and log out because you like to take your laptop home (which sounds almost like the purpose of having a laptop in the first place). The next day you arrive at the office, turn on the laptop, connect it to the omnipresent ethernet, and log into the machine (yes, you request a token again) and you check the output of you job … Not a good idea if you have a faint heart, or that data was really, really due, like yesterday.
Why, the innocent reader now asks? Well, clearly, because the output has not made its way to the file as you would have liked it to do. To cut short the story: the moment you logged out, your AFS token was revokes, or became invalid, or whatever, and the file that was greedily accepting your bits suddenly was inaccessible to your process. For example,

#!/bin/bash

i=0;
while(true); do
        echo "hup $i"
        sleep 1;
        echo "pup $i";
        i=`expr $i + 1`;
done;

woud yield this:

hup 0
pup 0
hup 1
pup 1
hup 2
pup 2
hup 3
pup 3
hup 4
hup 17
pup 17
hup 18
pup 18
hup 19
pup 19
hup 20
pup 20
hup 21
pup 21
hup 22

if you had logged out after 4 seconds and logged back in (and acquired a token) about 13 seconds later.

Boooooo! Eat that.

Of course, a simple workaround exists: save the data temporarily to a local file on the machine, e.g., in /tmp (and pray that the tmp dir is not wiped nightly). But that does kind of defeat the purpose of having a secure filesystem on which to store your data, does it not?

Tags: , , , ,
Posted in Uncategorized | No Comments »

AFS in ELIS

Wednesday, December 12th, 2007

Rejoice! I received a mail announcing my home directory and the files on it from the ELIS department would be moved to and AFS share.

I would need to change my password, and a new one was kindly sent to me in clear text. Nevermind the fact that accounts had been compromised easily in the past by sniffers installed on the local network, clear text clearly is the chosen way to distribute passwords, especially if users need to be moved to a more secure environment.

What I had heard in the previous months, or more accurately, year, did not give me much confidence this transition would go smooth. On the other hand, why would joe average (i.e., me) be transferred if the system still had some bugs? So, bold as I sometimes am (from a distance), I agreed to the immediate move. Most of my important data is residing on other machines anyway, so I figured, why not? Ah well. Let’s change the password, using the designated kerberos passwd utility. Cool. Except it was not. The next login using the new password did not work. I was happy to have kept the email with the clear-text password, as it turned out I needed it again. Changed my password again. This time it seemed to hold. My account had already been moved, but somehow the NFS server or client (I’ve no idea (yet) how those things really work) did not release the mount, causing the system to refuse mounting the AFS share for my home directory. A few emails sorted that out, after the sysadmin reset the NFS mount manually. So far, so good.

The next issue came up when I opened an SSH session to the ssh server at the ELIS department. Clearly, something was wrong. Even though I wound up in my home directory, and the SSH DSA key was used to get me logged into the system, I could not access any of my data. I checked using the fs command, which showed me I had all the rights in my home directory (rlidwka). But no way AFS was going to allow me to access my data, or even let me create a new file. It turns out that logging in with the SSH key is not a good idea, as the system then does not get you an AFS token. To get that, you need to manually request a token. This of course fubars the entire idea behind passwordless SSH usage (e.g., scp’ing files) because you need to execute an additional command such that you actually are allowed access to your files. Strangely, scp’ing a file actually works, if you are logged into your account. The leads me to believe a token is valid for a ll communications from a user. Weird. Basically, to scp data you need to execute two commands: one to get you logged in and acquire a token, and one to copy data.

I remain unconvinced. Normally, I am all in favour of using cool technology, but now, I am unsure.

Tags: , ,
Posted in Uncategorized | No Comments »