[OpenAFS] Home directory in AFS

[Jason Garman]

On Mon, Apr 22, 2002 at 10:16:08AM +0200, Turbo Fredriksson wrote:
> 
>     Charles> But by using a keytab, you're putting cleartext passwords
>     Charles> on ALL your workstations!!
> 
> NOW you're talking! Luckily theory and practise differs a little, and it's
> not EXACTLY as bad as enter the clear text password in a world readable
> file on disk. Close, but not quite...
> 
Actually, it's worse.  You're putting the keys for your entire AFS
cell in a file on disk.  Not world readable but this is worse than a root
compromise since it will compromise your entire cell and all of the users
contained within.

> Unfortunately I don't know any other way to get around this.
> 
Sure, just create the user's volume when you create the user.

Its already been stated why you should create a volume per user, but I'll
reiterate the advantages:

1) When you have to add more storage, you can simply create a new /vicepx
   partition and put the new users' directories on the new partition.

   Now -- you mentioned that you already have LVM and raid doing that work
   for you.  Well... if you have for example a concatenated disk set up,
   and you lose one disk in your disk set, guess what?  You lose
   everything.  When they're separate you just lose one disk.

2) If your cell were to expand to more than one machine (perhaps to add
   significantly more users or to increase performance) you can
   transparently move a subset of your users to the new server without
   interrupting service.

3) The backup system as mentioned before works on a per volume boundary.

The volume concept is *essential* to understanding AFS.  I suggest that
you bite the bullet and read the AFS administrators guide (at least the
part that explains how AFS was designed to work).  Don't read the whole
thing if you don't want to but *please* read at least the parts that
explain the terminology and design decisions!

> 
> It seems like I have to. I had just gotten used to the functionality
> that pam_mkhomedir gave me, so i didn't have to bother with the homedir
> until the user actually logged in, not wasting any space if it wasn't
> used.
> 
Okay now this is just ridiculous.  If you don't want to waste any space,
why not pick the easier route and create the directory when the user is
created (a few inodes "wasted" and a few more lines in your useradd
script), and copy in any startup files (eg from /etc/skel or
/afs/yourcell/common/etc/skel) into their home directory upon first login.
That would be so much easier to implement and a whole lot more secure than
the huge hack that pam_mkhomedir is even when used "properly".

If you had 50,000 users (which for example some AFS cells have) then the
space used by these directory entries would be a significant issue.  But
I'm assuming you're talking several orders of magnitude smaller here.

> I'm not convinced. Care to elaborate (WITHOUT calling me names this
> time)?
> 
>     Turbo> Not knowing quite what I'm talking about, this should be
>     Turbo> possible by using 'fs la' in a recursive loop under each
>     Turbo> volume, parse the info, and create a restore script that
>     Turbo> restores the ACL info... This script is created BEFORE the
>     Turbo> backup of the AFS volume takes place, and is backed up WITH the
>     Turbo> volume data.
> 
What you just described is way too complicated and will break in
spectacular ways.  The mantra "keep it simple" comes to mind here.

-- 
Jason Garman / jgarman@wedgie.org