On Mon, 26 Feb 2007, Jan Iven wrote:
<snip>
>> What is the correct way to fix this?
>>
>> Should I be adding the /lib64/security into the ld config paths, or creating
>> symbolic links in /lib/security to the correct paths, or should proftpd really
>> be looking for these libraries in their correction locations? (I can notify
>> the author if this is the case).
>
> Probably the last would be the best. Other service-specific PAM config
> file (under /etc/pam.d/) use something like
>
> /lib/security/$ISA/pam_rootok.so
>
> and the $ISA part gets expanded differently on 32bit and on 64bit (this
> is not a shell variable).
> So would suggest to change /etc/pam.d/proftpd to use $ISA for a test and
> then file this with the upstream author...

Of course $ISA has to expand to something pretty freaky for that path to 
work -- though indeed it does seem to do the right thing!!

Other pam.d/ config files seem to just refer to the module name with no 
explicit path, and that also seems to work, e.g. the default sshd entry:

   #%PAM-1.0
   auth       required     pam_stack.so service=system-auth
   auth       required     pam_nologin.so
   account    required     pam_stack.so service=system-auth
   password   required     pam_stack.so service=system-auth
   session    required     pam_stack.so service=system-auth
   session    required     pam_loginuid.so

In case you think that pam_stack/pam_nologin are somehow special, we add 
our local pam stuff (again without paths), and that seems to work for 
us...

   # DAMTP added part
   account    required     pam_simpaccess.so minuid=0

etc etc.

At some point the Solaris pam stuff stopped including the equivalent path 
(/usr/lib/security/$ISA) in the pam.conf too.  I can't remember when that 
happened though (too long ago).

Of course what you are supposed to do if the pam modules are installed in 
a non-standard location is a different matter!!

-- 
Jon Peatfield,  Computer Officer,  DAMTP,  University of Cambridge
Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/