Date: Tue, 3 Sep 2013 18:22:05 +0400 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Dag-Erling Sm??rgrav <des@des.no> Cc: freebsd-security@FreeBSD.org Subject: Re: OpenSSH, PAM and kerberos Message-ID: <20130903142205.GL3796@zxy.spb.ru> In-Reply-To: <864na2ujh7.fsf@nine.des.no> References: <20130902181754.GD3796@zxy.spb.ru> <867geywdfc.fsf@nine.des.no> <20130903083301.GF3796@zxy.spb.ru> <86y57euu8y.fsf@nine.des.no> <20130903093756.GG3796@zxy.spb.ru> <86ppsqutw7.fsf@nine.des.no> <20130903095316.GH3796@zxy.spb.ru> <86li3euovr.fsf@nine.des.no> <20130903115050.GJ3796@zxy.spb.ru> <864na2ujh7.fsf@nine.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 03, 2013 at 03:23:48PM +0200, Dag-Erling Sm??rgrav wrote: > Slawa Olhovchenkov <slw@zxy.spb.ru> writes: > > Dag-Erling Sm??rgrav <des@des.no> writes: > > > The application does not need pam_krb5's temporary credential cache. It > > > is only used internally. Single sign-on is implemented by storing your > > > credentials in a *permanent* credential cache (either a file or KCM) > > > which is independent of the PAM session and the application. The > > > location of the permanent credential cache is exported to the > > > application through the KRB5CCNAME environment variable. > > Yes, but content of credential cache got at time pam_authenticate(). > > Did you read *anything* that I wrote? I read. May be I bad writing, sorry for my english. > The pam_krb5 module obtains your credentials and stores them in a > persistent cache which is *independent* of the module and of the > application that called it. The *only* thing it needs to communicate to > the application is the value of KRB5CCNAME. If this wasn't the case, > pam_krb5 wouldn't work with *any* applications whatsoever, not just > sshd. Application don't know about KRB5CCNAME (in general case). And authenticate daemon don't know about KRB5CCNAME. How the demon can learn about need to transfer KRB5CCNAME to application? If called from application pam_krb5 change application environment or context and application don't worry about changes. All be done by PAM modules. > > Also, authenticate daemon (in case authenticate daemon call > > pam_setcred) can't be know what need to transfer (chaneged UID? new > > enviroment? deleted enviroment?) > > Actually, sshd already does most of this by farming PAM out to a child > process. > > DES > -- > Dag-Erling Sm??rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130903142205.GL3796>