David Morriss wrote:
> That makes sense. I assume that the intention was to provide an interface
> similar to $HASH_PASSWORD from Perl? If I were writing code just to
> interact with OpenVMS passwords I'd appreciate the decision :)
Yes the intention was to provide access to sys$hash_password - as is
mentioned in perlvms.pod
> [example of VMS Perl crypt snipped]
That example wasn't particularly vms specific (nor was it helpful regarding
the problem you are trying to solve).
> > However, vms perl does not have an implementation of Solaris' crypt
> > library nor its crypt() libc function and comparing the resultant
> > perl crypt()ed strings across systems is not guarenteed to yield
> > useful results.
>
> It's disappointing that this isn't possible. Experience with various Unix
> variants here (Ultrix, Digital Unix, Solaris, HP-UX, Linux) shows that the
> encrypted password strings can be shared between them - otherwise we couldn't
> use NIS of course. My intention was to use LDAP to emulate NIS (for the time
> being anyway) which forces me to use crypt() passwords, I believe.
>
> We've been managing our user data (registering students to use systems,
> changing passwords and quotas, etc) using OpenVMS for some time. I wanted to
> continue using OpenVMS with Perl to manage a copy of the user data in an
> LDAP directory - at least until I can replace this rather ancient legacy
> software with something better. This would involve managing crypt()
> passwords.
>
> What would be involved in providing a Unix-compatible crypt() function?
Take a look through the perl source, noting that on most posix systems
there are probes for a libcrypt.$your_unix_lib_extension
(`grep -i crypt Configure`).
Within the guts of perl things that deal with crypt
(`grep -i crypt *.c *.h | sed -e 's/:.*//' | sort | uniq`)
include these files:
embed.h
embedvar.h
intrpvar.h
iperlsys.h
keywords.h
opcode.h
opnames.h
perl.h
perlapi.h
pp.c
pp_proto.h
sv.c
toke.c
Note that vms redefines crypt into its own implementation in vms/vmsish.h
and vms.c (note too that subconfigure.com defines d_crypt as "define").
If you would like to see how another platform allows for the possibility
of adding your own local crypt implementation take a look at the win32/
port directory, where (apparently for US export law reasons?) the crypt
functionality is left "optional" and I think to add it you need to copy
your crypt source to a file called crypt.c (IIRC - check the source to
be sure about that).
If you really want to implement a unix compatible crypt then you might
want to take a look at a free implementation (e.g. the one with OpenBSD?) and
see if it could be adapted to be used as a module. Rather than overwriting
the core sys$hash_password crypt that vms already has you might want
to call your implementation Unix::Crypt::ucrypt() or something of that sort -
at least to start out with. If it proves wildly popular we could
see about reworking things (another configure.com question perhaps?)
> > For network verification things such as kerberos are a bit more robust.
> > Kerberos services for VMS are available as part of the Multinet TCP/IP
> > product e.g.
>
> I'd love to use Kerberos, and may well do so in time, but it isn't a drop-in
> replacement for what we have now.
Yes I do realize that. I would still recommend taking a look at the OpenSSL
(not OpenSSH) stuff however since it has already been ported to OpenVMS.
Peter Prymmer
