[OpenAFS] Home directory in AFS

[Derek Atkins]

Turbo Fredriksson <turbo@bayour.com> writes:

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

No, it's actually the opinion of a lot of us.  Here's the problem:
assume you have an enviornment with 1500 workstations; this means you
have your system:administrator key in plain text (a krb5 keytab is
essentially plain text) sitting on 1500 machines.  As soon as someone
breaks ONE of your workstations (like, say, rebooting in single user
mode) they now have system:administrator privs in your cell.

You have now reduced the security of AFS down to (or even worse than)
what you get with NFS!

> 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' :)

Sure, many of us do that.  However perhaps there are other approaches
that will do what you want, too.  As I mentioned, why not have your
web page that creates your user accounts also create entries in the
PTServer and create the user's homedir volume in AFS?  It's still
writing code, but it will fit the design model and is something that
will actually _work_.

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

No, it is exactly as bad.  A keytab _is_ a clear text password, just
in post-string-to-key format.  If someone can read your keytab, they
can 'kinit', get tokens, and are now system:administrator.  This is a
Bad Thing (TM) if you care about the integrity of your file system.

> Unfortunately I don't know any other way to get around this.

There are a number of approaches.  The most common one is to have a
server daemon attached to a database (ala Moira, or LDAP) and have
automated account creation centralized instead of distributed.

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

You do realize that an empty homedir only takes up a couple of inodes,
right?  Why are you trying to optimize for maybe 4k of on-disk
savings?  Is this optimization really buying you anything in reality,
other than adding complexity to your system?

> 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 :)

Then perhaps you should go spend $2k and take an AFS class, or hire
someone to come in and show you / teach you how AFS works?  If you
can't spend the time to learn at least the very basics about how a
complicated system like AFS works, why should you expect free support?

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

I disagree.  I cannot imagine a SINGLE case where pam_mkhomedir is a
necessary tool, unless all home directories are ephemeral.  If you
have a distributed file system, your home directory should be created
at the same time that the account is created in all your other
centralized databases.  Why distribute this function when you have to
centralize all your other functions?  It just adds complexity for zero
added benefit.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available