[OpenAFS-devel] kpasswd (S/390)

[Derek Atkins]

We're talking solely about Red Hat Linux packaging, not OpenAFS in
general.  You clearly don't want to use the pre-packaged Red Hat
packages.  That's fine.  There is no requirement to do so.  You
can still build OpenAFS yourself and then install the tree into
/usr/afsws as you see fit.

However, there are a number of people (in particular the new, small
OpenAFS users) who _DO_ want AFS integrated into their machines,
rather than the larger, old-AFS hands who want to centrally control
their code.

-derek

"Todd M. Lewis" <utoddl@email.unc.edu> writes:

> 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 /
> +------------------------------------------------------------+
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

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