[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Generalisation of Display Agent Selection
- From: Andrew Morgan <morgan transmeta com>
- To: pam-list redhat com
- Subject: Re: Generalisation of Display Agent Selection
- Date: Wed, 01 Dec 1999 21:39:40 -0800
...back to discussing your comments. [ Its crazy having a day job! :]
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?
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.
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'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.]
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.)
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.
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.
Is this 'solution' too indirect? Could you see this working/satisfying
[Date Prev][Date Next] [Thread Prev][Thread Next]