Status of VOS password issue

John E. Malmberg wb8tyw at
Fri Jul 28 06:27:53 GMT 2000

Ron Alexander <rcalex at> wrote:
> What I did was:
> 1. Finally figured out that I had to enable the HAVE_CRYPT #def.
> 2. Created a crypt.c module that calls the VOS equivalent function. I did
> that way to keep the change external to samba.

I did the same for OpenVMS.  However in OpenVMS, the encrypted password hash
also contains the username, so I have to assume that the call to crypt() was
preceded by a call to getpwnam(), where I have saved the last information

> 3. Created a sys_getpwnam function (also had to drag along setup_pwret
> it is static). It calls the normal getpwnam as before, but I then called
> VOS function that gets me the encrypted password. I copied that into the
> normal pw_ret and from that point on everything works as before.

I used a wrapper for the getpwnam() function supplied by OpenVMS, and in the
function that I use, I return all the information that SAMBA expects, not
just the stuff the supplied function does.

> 4. What might seem unusual, is that I created an external module with the
> same name as an existing function. The reason is, I avoid having to either
> make the change next release, or feeding it to you with ifdef VOS. The
> is to show it to the binder (linker) first so that the normal function is
> not used. It does generate a warning about duplicate names, but I can live
> with that. I used the same trick to modify the behavior of the stat and
> code in order to support a VOS specific file type.

I previously posted an alternative method of overlaying a samba module with
an external routine of the same name.

In the MAKEFILE equivalent, for the C complier command line, I have an extra
define for the symbol MOD_nnnnn.  Where "nnnnn" is replaced with the module
being compiled.

Then in config.h I have #ifdef MOD_nnnnn for the module.  For example, VMS
has some options that are not available in smb.conf, so they are implemented
using a form of environment variable.

So in the module where lp_load() resides (I think PARAMS.C), for the file
config.h, I have:

#define lp_load samba_lp_load

And my own module vms_lp_load.c has a routine lp_load() that when it is done
with it's setup, calls samba_lp_load() to complete the job.

This avoids the duplicate symbols warnings from the linker.  It does not
work where the routine to be overlaid is called from elsewhere inside the
same module where it resides.

(I have been offline for over a week, and not all the systems have been
powered up, so I am writing from memory, so please excuse minor

wb8tyw at

More information about the samba-technical mailing list