[OpenAFS] Home directory in AFS

[Todd M. Lewis]

Turbo Fredriksson wrote:
> 
> >>>>> "Charles" == Charles Clancy <security@xauth.net> writes:
> 
>     Turbo> So just configure pam_mkhomedir to recognize a KerberosV
>     Turbo> keytab, do the 'kinit', then the 'aklog' (both with propper
>     Turbo> options) equivalences in C.
> 
>     Charles> For the 3rd or 4th time, this is a BAD IDEA.
> 
> That's YOUR opinion. You have yet to PROVE and/or give a GOOD example/reason
> for why this is a bad idea. All you manage to do is call me names.

It's a bad idea because if (make that when) one of your hosts gets
hacked, the bad guys get not only that host, but they get admin
privileges in your cell.

>     Charles> If you're
>     Charles> going to put admin keytabs on all your workstations, just
>     Charles> USE NFS.  It would be MUCH more secure.  Your trying to
>     Charles> turn AFS into something it's not.
> 
> Perhaps. I've always succeeded making software designed to do one thing,
> do the things _I_ want it to do. Usually by 'adding some random bits of
> code' :)

I can appreciate your motivations, but if I may make a suggestion... You
would do well to try running AFS the way it was designed to run until
you understand it.  Then, if you still want to make changes like you are
suggesting, you will at least be making informed decisions.

>     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...
> 
> Unfortunately I don't know any other way to get around this.

Without being to sardonic, the way to get around this is to do it the
AFS way.  That's basically why it was set up this way to start with.

You seem to be thinking that you will admin all the machines in your
cell.  Not true.  Anybody in the world can set up a client, configure it
to be part of your cell, and if you've not firewalled yourself away,
it's part of your cell.  To _use_ it productively, somebody on that box
needs to know a principal/password from your cell, but this is a good
thing -- it gives your users great flexibility, and frees you from
having to do any cell level administration on individual boxes.

This is a key feature of AFS, and worth repeating since this seems to be
one point you are missing: You don't have to do any cell level
administration on clients.  Don't put admin keytabs out there.  If you
do, you're working too hard, and decreasing security.

>     Turbo> So having the pam_mkhomedir is ESSENTIAL for this to work
>     Turbo> properly. Fine, hard work. I don't mind :) In theory it's not
>     Turbo> THAT hard, but we all know that theory and practise differs :)
> 
>     Charles> Umm... why can't you create a home directory from this
>     Charles> web interface?  At least you'd only have to put a keytab
>     Charles> on one machine.

That's what we do; all our users are created through a web based front
end.

> 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.

AFS volumes only take us the space they actually use, not what their
quota allows.  A few template dot files don't waste a lot of space.

>     Turbo> This is a bummer. Is it possible to only backup the ACL
>     Turbo> information, without taking the data?
> 
>     Charles> Nope.
> 
> I'm not convinced. Care to elaborate (WITHOUT calling me names this
> time)?

Of course you can harvest ACLs and store them in some format that allows
you to restore them later.  But all that work is already done for you
with AFS's volume dump, restore, and backup procedures.  You don't have
to restore backed up volumes to their old names, so if you want to do
easy web based partial restores, put your work into restoring the volume
in the background, then grabbing for the user just the files s/he
wants.  And ACLs too if that's what you're after.  Inventing AFS backups
again is lots of work, and it's already been done.  Build on it, but
understand it first.

>     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.
> 
>     Charles> Wow.  Use NFS.
> 
> NFS sucks.

Okay, we've reached a point of agreement! :-)  You could recursive "fs
la", but there are library calls you could use as well to keep from
having to invoke external programs over and over.  The point is, don't
do this until you really understand how AFS was designed to work.  If
you then feel it's worth the effort, you can make informed decisions
about whether this is a good idea.  The fact that experienced people are
suggesting (rather strongly) that it isn't a good idea should tell you
something.  Understand their reasons before you spend to much effort
turning your AFS cell into less than it could be because that was the
vision you had when you started with AFS.

> I have no big problem with this. As long as I get INTELLIGENT and real
> reasons why something is bad, fine.  Just calling me names isn't going
> to help.

I vaguely remember thinking some of the same things about how we should
run things around here before I "got it".  Frankly, I would like to see,
for example, a web based interface that allowed file level restores
under user control.  But knowing what I know now, I wouldn't dream of
building it from scratch.  It would have to sit on top of the volume
level backup/restore system AFS provides.  It's just too good not to use
it.

> Yes, I'm much like you, but those times I've been 'sardonic' (I've
> actually been worse) is when it clearly is in the FAQ/HOWTO. In this
> case (OpenAFS/AFS in general) the manual is 6-700 pages long! I just
> can't read that much without straining a vessel :)

Ah, but it doesn't work like anything you're familiar with.  If you want
to use it like NFS, use NFS.  As you said, NFS slurps.  I suspect AFS as
NFS would slurp too.  But there are those of us who don't like to think
about (computing) life without AFS.  Maybe those 700 pages are relevant
to understanding why.

>     Charles> In my opinion, you are completely missing the point of AFS.
> 
> Very possible. Maybe I want something more, maybe something less. If it
> "won't do my bidding"  then I'll try to MAKE it so that it does.

Better to invest that energy, at least initially, into understanding
what AFS can do for you, even though it's not what you think you want.

> I still think that the 'pam_mkhomedir' module would be nice to have, added
> the needed functionality.

I'm not sure what all 'pam_mkhomedir' does.  I assume it creates a home
directory and adds a user to the passwd/shadow files.  I've made a pam
module that adds our valid users to the passwd/shadow files if they
aren't already there, but the home volume/directories are created when
their accounts are created.  One reason is that different classes of
users get added to different groups, they get different quotas, and
maybe some other things I can't think of right now, but the point is all
the information I need to make those decisions are known at user
creation time (userid creation that is) and may not be available to the
first workstation they login to.

>     Charles> From everything you've said, I strongly suggest you stick
>     Charles> with NFS.  It would be more appropriate for your
>     Charles> environment.
> 
> I have. NFS gave me more problem than it was worth, I need something
> completely different. And I might even USE NFS in some areas, but
> I first going to explore the 'whole' (at least as much as I have
> to to understand it enough) AFS business.

Well, AFS is completely different all right. I have the same tendency
you seem to have -- to try to coerce a "new" (to me that is) system into
my existing mental models of how computing works.  Try to work with it
instead of against it until you understand why it is the way it is.

And by all means, keep asking questions.  Just be prepared for answers
that don't always make you happy.
-- 
   +----------------------------------------------------------------+
  / Todd_Lewis@unc.edu                  http://www.unc.edu/~utoddl /
 /(919) 962-5273  Linux - It's now safe to turn on your computer. /
+----------------------------------------------------------------+