Hi, > It looks like you are assuming the current state of the things > while I argue that it should be changed. That is, we are talking about > different things. >From your initial posting : ---- Nevertheless I do not want to hack a separate *program* that would talk to the authentication service of my choice (say look into $HOME/etc/passwd for my screenlock password hash, not really :). I want to use the wonderful libpam and the modules! ---- Ok.. We want to able to specify where to find the runtime config. Recompiling every program isn't really an option. We might me able to do it throught the runtime linker, in the PAM startup code. > Well, *where* do they get the options from? From a file... > My point is that I should be able to specify that file's location, > instead of a compiled in one. We might wat a seperate function that can be called, to tell PAM where to find it's config. We do however need to drop privileges if we use non-default confis. > > > > config-file=..... will do I think :) > > > > > > Where would you put that spell Igmar? Into a file? :) > > > > Into an option. Try actually looking in a module's source before saying > > things that aren't correct. > > I hope my explanation above is sufficient to avoid further confusion. It is indeed. We had different interpretations of things. > [let's avoid going personal and questioning each other's qualifications, > I *have* read the sources, and lots of other stuff too :-] > > > > - I want to use existing pam-aware programs without modification > > > > The mods are done in PAM, programs have no business in knowing with PAM > > does beneeth. > > Sure. That's why I want to use PAM, it is a very convenient layer to > configure programs dealing with authentication. > > You may think that root is the only who is interested in authentication. I > am trying to show that it is not the case and that PAM is hardly adequate, > in its current state, for locks on user-owned resources (e.g. sessions). If a non-root user authenticates credentions you're somewhat limited : - You can only use files you own - You can use network servives if you have credentials to use them > > > but I cannot rely on the existence of a file in any "well known" > > > compiled-in location, even a "well-known name in the homedir" would > > > *not* (!) work in the long run > > > > Why not ?? The .bash_profile in a user's homedir has been there for ages > > and you're telling me that won't work ?? I can name a dozen of programs > > that do similair behaviour. > > Right, I am telling you it wouldn't work. > > Dot-files are a very old (and in many ways broken) concept. > They break incredibly fast as soon as you want to have a > configuration-per-process, not a configuration-per-program, > unless you run your programs as > > prog --config-file <instead-of-the-default-dot-file> You usually want multiple instantiations of a program to behave the same. You have to tell the program somehow what you want it to do, and that is limited to options and env vars. > And *that* (a "command line option") you cannot easily do with PAM. > A special environment variable would be a convenient way to point to > different configurations, then. I'll check if we can access argc / argv from the .so startup code. > (remember that for login-services - sshd/xdm/younameit - *the user* is > still root) sshd under user control is a VERY bad idea, it bypasses all things root has set up. Marry Christmas to all !! Regards, Igmar _______________________________________________ Pam-list@redhat.com https://listman.redhat.com/mailman/listinfo/pam-list
