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

Re: pam_session bug?

The more I think about this, the less it seems appropriate for us to
rely on any uid convention for authentication purposes.  Perhaps it is
sufficient to state the PAM_RUSER is the user originating the request
and PAM_USER is the user to be authenticated?

I think this is so basic, it can even be made to work with Solaris.

The problem with inferring all this from uids of one sort or another
is that it means we cannot use PAM for databases and other
applications that enforce their own security/credential model
(independent of the kernel).



Derrick J Brashear writes:
> On Thu, 7 May 1998, Savochkin Andrey Vladimirovich wrote:
> > Could you check the kernel credentials with which different
> > PAM functions are called under Solaris?
> Not at the moment, probably by the weekend, but if I recall ESTABLISH_CRED
> is called as uid/euid root in dtlogin and as uid/euid user in login. but i
> will check.
> > I'm mostly interesting in uid, euid, gid, egid and supplementary groups
> > for calls pam_open_session, pam_setcred(PAM_ESTABLISH_CRED),
> > pam_setcred(PAM_DELETE_CRED), and pam_close_session
> > when you do for example "su - user" with the original and the target
> > users being not root. The test could be performed easily by plugging
> > a module which prints the information.
> when i bring *any* solaris 2.6 machine back up:-)
> > Now we can't say that the compatibility is present because
> > we aren't sure that the policy of setting kernel credentials
> > when pam_sm_setcred module function is called
> > differs under Linux and Solaris.
> sure, it's compatible. you have no clue what kernel credentials you'll
> have, so you have to program for that. i don't like it, but it is
> compatible:-)

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