[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pam library (and dependancy) policies

On Tue, 2002-08-20 at 10:35, Steve Langasek wrote:

> <shrug>
> $ dpkg -L libpam-smbpass | grep so
> /lib/security/pam_smbpass.so
> $ ldd /lib/security/pam_smbpass.so | grep /usr
>         libcups.so.2 => /usr/lib/libcups.so.2 (0x40096000)
>         libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x400f5000)
>         libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x40106000)
>         libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x4015b000)
>         liblber.so.2 => /usr/lib/liblber.so.2 (0x4016c000)
>         libldap.so.2 => /usr/lib/libldap.so.2 (0x40178000)
>         libsasl.so.7 => /usr/lib/libsasl.so.7 (0x402cd000)
> $

ahh yes, I had forgotten about ldd. I had thought that my lib would be
similar to pam_smbpass but didn't know what to check, thanks.

> Basically, any PAM-enabled app that needs to function before /usr is
> mounted (are there any?) can't reference such a module in its PAM config
> file.  If the module itself is in /usr, it will fail; if the libraries it
> depends on are in /usr, it will fail.

I was thinking more along the lines of an error condition causing /usr
to be unmountable rather than using pam 'before' /usr is mounted.  I
could see (at least w/ my pam lib as opposed to smbpass) a situation
where even root cannot login to a box where /usr is borked if they're
required to have a working PAM.  I guess there's always single user

> But once /usr is mounted, it doesn't matter where the files are, so
> putting the module in /lib/security with all the rest of the PAM modules
> is as good a place as any.
> Since no Debian policy can keep admins from referencing files in /usr
> when they shouldn't, I think this is as good a solution as any.

True, but we can build our software and packages to avoid such
situations.  What the admin does is his fault/problem - by choice.  What
we build into the system is ours.  

I suppose you could argue that the admin *chose* to enable my PAM lib
and so should understand the implications.

> This is not policy, but it's the status quo; I can find at least 3 other
> PAM modules in Debian that handle this the same way.

fair enough.


     Innovation Software Group, LLC - http://www.innovationsw.com/
                Computer Automation Specialists
                 UNIX, Linux and Java Training

Reply to: