On Tue, Aug 20, 2002 at 11:21:18AM -0400, Joe Phillips wrote: > > 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 > mode. With the exception of /bin/login, most PAM-enabled services are not available when /usr is unmounted. If your site security policy depends on something like Kerberos, then you're going to need /usr for local logins regardless of where the login binary itself is located. So if you're in that situation, you're pretty much left with single user mode as your only option. > > 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. Yes, that's what I would argue. :) Steve Langasek postmodern programmer
Attachment:
pgp150kctGL7y.pgp
Description: PGP signature