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

Re: An "orthogonal" way of using libpam



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
     *   *
     .\'/,
   *-- * --*
     '/,\'
     *   *





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