Hello Igmar!
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.
On Tue, 24 Dec 2002, Igmar Palsenberg wrote:
> > Huh, libraries do not have options, it is executables who get them.
>
> No. It is perfectly legal to specify options to PAM modules, and the
> module get's the argc / argv in the pam_sm_* functions.
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.
> > > 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.
[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).
> > 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>
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.
> > [the same program that calls the same pam-service may have to be run
> > by the same user with different module- and rule- sets at different
> > times or even simultaneously ]
>
> You can't. Users can't control what PAM does. Services get called using a
> static set of arguments.
Yeah! You see my point. It is the deficiency I'd like to fix. I want that
the user would be able to control what PAM does, for the user's purposes.
(remember that for login-services - sshd/xdm/younameit - *the user* is
still root)
Said that I'd like to finish the discussion, i.e. I leave making the
conclusions to the main developer.
Sure, I volunteer for testing, if there will be any relevant changes to
test! I *need* such changes to get rid of workaround hacks...
Best regards Igmar,
and Merry Christmas to all of us on the list!
--
Ivan
* *
.\'/,
*-- * --*
'/,\'
* *
_______________________________________________
Pam-list@redhat.com
https://listman.redhat.com/mailman/listinfo/pam-list
