On 10/06/08 15:41, Joerg Barfurth wrote:
> One thing I am missing here is a way to use this module with explicitly
> specified authorizations, but without requiring one of the
> solaris.login.* authorizations (or with an additional one).
>
> PAM is being used to authenticate and authorize access to services that
> are not really system login access. Some examples I can think of from
> the Sun Ray are are registering Sun Ray devices or smart card tokens for
> use with the system or access to the Sun Ray administration web console.
> In both cases it makes sense to use the usual name services and
> authentication mechanisms for the user accounts, and it would be great
> to use an authorization to manage the administrative roles, but in
> neither case is login or login-like access granted. (From the PAM side
> this is reflected in that the session module functions are not used.)
See below for how to avoid the need for solaris.login. authorizations.
> BTW: Do you plan to document in more detail how the distinction
> console/local/remote is made by the module? What combinations of
> PAM_TTY, PAM_RHOST and other items must a PAM client set in order to
> signal one of these cases?
If PAM_RHOST is set we check for solaris.login.remote;
if PAM_TTY is /dev/console we check for solaris.login.console;
if PAM_TTY is something else and PAM_RHOST is not set we check for
solaris.login.local.
If PAM_TTY is unset and PAM_RHOST is unset we don't check for any
solaris.login.{local,remote,console} authorization.
Bart
