[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Generalisation of Display Agent Selection
- From: "Craig R.P. Heath" <craig sco com>
- To: pam-list redhat com
- Subject: Re: Generalisation of Display Agent Selection
- Date: Thu, 02 Dec 1999 19:14:34 +0000
At 09:39 PM 12/1/99 -0800, Andrew Morgan wrote:
>...back to discussing your comments. [ Its crazy having a day job! :]
Thanks, I appreciate your time (I'm just glad I'm paid to do this:-).
>I'm hoping that this is a fair summary of your posting:
> 1. client applications already have a customized touch and feel to
> 2. if we are going to plug in some sort of code (an agent) to extend
>the client's (G)UI, it should be possible to do it in a way that doesn't
>look bad/clash with the client app.
> 3. it seems natural that the application should thus have some control
>over which agent is chosen as a "generic display agent".
> 4. it seems that there is some method for a client application to send
>binary prompts to the server, and thus the current libpamc
>implementation might be in a position to achieve what you want, with
>perhaps a bit more in the way of pre-defined BPC types. Is this so?
Yes-ish. I'm just looking for a way to do it within the libpamc
model if at all possible.
> 5. it seems appropriate that there be some sort of standard method for
>'initialization'/'synch up' of such things as the prefered display
>agent, pam-items and perhaps server-side PAM-environment variables.
Yes, although I see this as potentially a separate issue.
>I guess the reason why we've not come to a quicker consensus on this is
>that I hadn't realized the fact that your perspective is different from
>mine. You are looking at this problem from the point of view of a client
>application writer, and I'm looking at it from the perspective of a PAM
>module. Yours being, how can I modify an application to seemlessly
>integrate with a myriad of to-be-written agents, and mine why is it that
>PAM can't support the next flavor of authentication (over a network)?
I wouldn't have put it quite like that; indeed, working as I do for an
OS vendor, my perspective is primarily from the systems software side.
Ultimately, though, platform software is only of value in so far as it
is used by applications, and this particular look-and-feel requirement
actually originates from application vendors (and came to me from the
BioAPI Consortium via the Open Group). [Actually, "middleware vendors"
might be a more accurate description than "application vendors"]
I'm trying to get some more input from the BioAPI consortium, but as
they don't publish their working drafts I haven't got any yet.
>I'm hoping that my long 'history of libpamc' was clear enough to explain
>the perspective that led to the current client library. So, let me
>respond to the above points (as I have numbered them) and then ask some
>questions - I trust you'll revive any bits that I've inadverently
>1. is indisputable. No contest.
>2. seems like an important goal and I agree it should be possible to
>conveniently accommodate it in some fashion.
>3. from the perspective of an incremental addition to a client
>application, it seems natural that a client would like to assert some
>sort of influence on the look and feel of an agent's (G)UI. The question
>I have is whether this is something that the client needs to have
>defined at the point when it was written (by the author), or whether its
>more something that should be defined at run or install-time via some
>client-specific customization file? And left for a
>vendor/distributor/sys-admin/applicant associated with the client to
>make a preferred selection? My opinion is that this sort of thing is too
>sensitive, and subject to 'the authentication scheme you hadn't
>anticipated' to be a concrete decision that the client's author could
>make once and for all. I'd favor some sort of default config file that
>the author might distribute, but that is something that someone closer
>to the applicant could actually customize. [A possible implementation of
>this is given in 5.]
This is an interesting point, and I don't have a problem with the
ultimate decision being in the hands of the client sysadmin.
I'm not sure I've adequately explained the sort of control I'm wanting
the client app to be able to have. What I'm thinking of is, the client
app puts up some sort of form on the display, leaving a space within the
form for the authentication dialogue. There exists a display agent, which
the application developer considers a close-enough match for their look
and feel. This display agent picks up the location and size of the space
allocated for it (probably using PAM_BPC_GETENV) and displays the dialogue
on behalf of the module that is invoking it. It needn't work precisely
like that, of course - suppose I have a display agent specifically for
Motif, it might get passed a widget handle somehow, which would be much
better than a fixed screen area if it needed to be resized and so on.
I don't really care whether that association is hard-coded or in a
config file, but I do feel that it is something that the application
developer needs to specify. If the app is supplying a screen location
but the display agent is expecting a widget handle, it's not going to
work. Now if the sysadmin knows that they have another display agent
which expects a screen location, then fine, let them configure it, but
I don't think that's something we should require them to do.
>4. actually, I believe that the current implementation of libpamc is
>designed to make what's described in (4) very hard. The current paradigm
>is that a server-side module drives the authentication. In other words,
>for a client app to send a binary prompt it would have to have been
>requested by a module. Unsolicited binary prompts have no one to vet
>them for harmlessness and that makes me nervous. (This is actually also
>a backward compatibility issue, insofar as one of the design goals for
>libpamc was that it could be used in conjuction with all current
>implementations of libpam. I believe that we've achieved this goal,
>although to my knowledge, this assertion has not been confirmed by
>anyone. All that one should need to do is extend the pam_*.h files to
>define the PAM_BINARY_PROMPT conversation type, something that would not
>require that libpam is recompiled.)
I don't think I agree that "a server-side module drives the authentication",
although this may only be quibbling with the words. Taking it from the
top, the first thing that gets executed is the client application. This
connects to the server application, at which point the server application
decides the user of the client app needs to be authenticated, and calls the
PAM library. The PAM library checks the config file and sees that certain
modules are associated with this server app, so it goes ahead and executes
them. Then a module may decide it wants some input, so it calls back to
the server app. which causes a request to be passed to the client app, which
it acts upon. In that context, I think the server app drives the
authentication, although modules drive the conversation with the user
during that authentication (which is probably what you meant anyway:-)
I certainly agree 100% with the need for backward compatibility - the primary
value of the PAM framework is in the large number of service modules that are
currently available, and anything we did that broke compatibility with them
would be a non-starter in my opinion. I wouldn't rule out the notion of
requests from the client that get processed by the PAM library (without being
passed to a module) though - or in other words, I'm willing to change the
framework as long as it's backward compatible with existing applications and
modules. I don't think that makes things much worse; if you want to use the
new features in libpamc you need a new application and a new module. If we
change the framework (in a backward-compatible way, of course), you need a
new application, library and module. If you're building a new application
anyway, linking it with a new library doesn't seem to be much extra work.
>5. I guess this is my one opportunity to say this is how you could do it
>with libpamc as is... First, I'd like to state that I think its really
>important that a server's sys-admin should ultimately own the choice of
>authentication methods available to get service from a server.
> I see the
>choice of how the server gets to learn about things like PAM_RUSER as
>very much part of this authentication choice. It is certainly the case
>that current client-servers pass things like the name of the 'RUSER'
>around without much security. S- and R-sh, for example, simply send it
>to the server. There is no effort to attach any credibility to this
>value and this is why a .rhosts entry of '+ morgan' are really silly
>entries to have outside a trusted secure network. A fully PAMified set
>up should be able to support this, and to override it by a simple
>arrangement of modules.
>So, if the admin is going to be willing to accept 'initialization'
>and/or 'synch' up defaults for their server, I strongly feel it should
>be activated by them placing a 'pam_XX_init_XX.so' entry as the first
>'auth' entry in the PAM config file for their server application. This
>'XX_init_XX' module would request the services of a corresponding agent,
>and an entry like:
> auth optional pam_XX_init_XX.so
> auth required ...
>would mean that not all clients would be have to support the
>corresponding agent for the authentication to proceed. The client-side
>agent could read these values from a file or a database or whatever. I
>think this is how things like a preferred display agent and/or default
>RUSER or environment variable setting etc., could be pluggably defined.
>It also means that an admin can plug in a replacement module should the
>current module be found to have some flaw.
An interesting idea - I need to think about this some more. I'm a bit
wary about that agent running in a separate address space, but I suppose
it could use PAM_BPC_GETENV to get things from the client app, so it
>Clearly, the application writer might have some recommendations for the
>preferred display agent id, but ultimately, the final decision would be
>in the hands of the V/D/SA/U.
I see it as somewhat more than a recommendation - a default, really. If
the module or the client sysadmin really want to use something else, they
should be able to, but typically I wouldn't expect them to.
>Is this 'solution' too indirect? Could you see this working/satisfying
It could do. At this point I should probably go away and actually try it.
I have been thinking of a more radical alternative this week, but I'll
try your suggestion first.
Stay tuned :-)
[Date Prev][Date Next] [Thread Prev][Thread Next]