[OpenAFS-devel] kpasswd (S/390)

[Todd M. Lewis]

Carsten Jacobi wrote:
> 
> By the way please add the entry for "/usr/bin/kpasswd" to
> the general SPEC-File! Everybody who used AFS for years is
> used to change his AFS password with this program. And since
> kpasswd works fine now also on Linux-S/390 I wonder why it
> should be left out of the RPM.

Well, kpasswd is supposed to use kpwvalid to strength-test passwords.
The default kpwvalid only tests for password length, but we have
implemented further tests. (Whether that's a good idea is open for
debate, but not my point.) Having briefly looked at the code, it looks
like kpasswd will only trust kpwvalid if they are both in the same
directory, they are both in AFS, and they are both in a directory tree
that's writable only by admins. Moving kpasswd and kpwvalid to local
file space makes these test worthless. (Of course, everybody's got the
source these days, too, so I'm not sure it matters anymore.)

So, what're the security implications of having a local kpasswd, when
everybody and her sister has full source to the OS, the AFS client (and
server), and admins the cell for fun/profit?

Also, why the push to move /usr/afsws/bin and /usr/afsws/etc to local
file space? We'd prefer to have these be symlinks to directories in AFS
where we can manage them. Pushing all that out to the clients seems
warm/fuzzy to those of us who like to get bits all over our hands, but
the average user doesn't care, and would be better off with fewer files
on his client to have to worry about. Not to mention that all our admin
scripts that have full paths to various /usr/afsws/etc and
/usr/afsws/bin utilities hard-coded into them don't work with vanilla
OpenAFS clients. Blech, etc.
-- 
   +------------------------------------------------------------+
  / Todd_Lewis@unc.edu              http://www.unc.edu/~utoddl /
 /(919) 962-5273     Official Signature of the New Millennium /
+------------------------------------------------------------+