Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

I have been using sys-auth/pam_krb5-2.2.6 with a Heimdal 0.7 series KDC on x86
and amd64 for two months now with no problems.

Please change the DEPEND to virtual/krb5 and keyword the package into ~arch
instead of -*.  This is the only pam_krb5 I've found that can correctly handle
fetching openafs tokens (when used with a heimdal KDC), obviating
pam-openafs-session for all cases except SSH with GSSAPI key-exchange but no
OpenAFS ticket passing.

This is already fixed in 20030601 and 20030601-r1.

This is not a valid solution.

pam_krb5-2003* and pam_krb5-2.2.6 are two entirely different packages - look at
the SRC_URI in the ebuild and the DESCRIPTION.

2.2.6 comes from Fedora, whereas 2003* is from the SF.net pam_krb5 project.

They share the same name, but 2.2.6 works properly with OpenAFS and OpenSSH
where 2003* does not.  The pam-2003* series also does strange things like
depending on kth-krb if the "afs" USE flag is set.  Please keyword this
package.

I second that motion. I am using 2.2.6 on a production server and I am going
through hell unmasking / keywording it correctly due to misversionning.

(In reply to comment #2)

> They share the same name, but 2.2.6 works properly with OpenAFS and OpenSSH
> where 2003* does not.  The pam-2003* series also does strange things like
> depending on kth-krb if the "afs" USE flag is set.  Please keyword this
> package.

Yah, 2003* does indeed put a dependancy on kth-krb, but unfortunately claims
that pam_krb5-2.2.6 work with everything out of the box are slightly
exagerated. 

2.2.6 attempts to validate allowed logins by reading the .k5login.  This is
cute and all, but it apparently attempts to do this before aquiring the AFS PAG
even though the authentication succeeds.  Unless all logins make $HOME
system:anyuser readable, then pam_krb5-2.2.6 fails the login due to recieving a
permission denied error when attempting to open ${HOME}/.k5login.  Making
${HOME} paths system:anyuser globally readable in order to make pam_krb5-2.2.6
function is quite frankly "not a valid solution".  Particuarly since AFS
directory acl's are inherited from the parent directory.  Every new directory
created under ${HOME} would be created with system:anyuser read permission.

The claim that pam_krb5-2003* does not work with OpenSSH is also exagerated. 
It works correctly so long as OpenSSH is capable of handing off the credential
data correctly.  This gets into a bit of a religious war that has been going on
between OpenSSH and pam for quite a while.  OpenSSH can't pass the credentials
unless compiled with pthread support, but they have gone out of their way to
make enabling pthread support difficult because people want to enable it
thinking it improves performance, and for some reason OpenSSH isn't content to
let people live with their own opinions and decisions.

pam_krb5-2003* does not have this problem.  Unfortunately, kth-krb is a dead
project and not all of the pieces are in place to remove it from the systems
yet.  Such as this pam issue.  The only problem with pam_krb5-2003* that I know
of is the dependancy on the kth-krb package.  The OpenAFS and OpenSSH claims
are both ficticious, and misleading.

Lastly, as noted, pam_krb5-2.2.6 does not work with OpenAFS unless one changes
local security policies in order to allow it to read ${HOME}/.k5login on AFS,
and there is no way to disable this check w/out disabling local account
validation completely.

(In reply to comment #4)
> 2.2.6 attempts to validate allowed logins by reading the .k5login.  This is
> cute and all, but it apparently attempts to do this before aquiring the AFS PAG
> even though the authentication succeeds.  Unless all logins make $HOME
> system:anyuser readable, then pam_krb5-2.2.6 fails the login due to recieving a
> permission denied error when attempting to open ${HOME}/.k5login.  Making
> ${HOME} paths system:anyuser globally readable in order to make pam_krb5-2.2.6
> function is quite frankly "not a valid solution".  Particuarly since AFS
> directory acl's are inherited from the parent directory.  Every new directory
> created under ${HOME} would be created with system:anyuser read permission.

I retract this statement.  It seems that the pam_krb5-2.2.6 requires the
"token" argument in more sections then pam_krb5-2003* did.  I now have
pam_krb5-2.2.6 requesting tokens in the auth, password, and session events, as
well as needing use_shmem=sshd in the auth and session events to get around
openssh's inability to hand off credientials between these stages of
authentication.

I have just been going through intense torture with the other two pam_krb5's
and AFS with Heimdal, and after reading this bug I unmasked 2.2.6 and tried it,
and it's been working perfectly in a production environment. This absolutely
should go in ~arch.

(In reply to comment #5)
> (In reply to comment #4)
> > 2.2.6 attempts to validate allowed logins by reading the .k5login.  This is

I have seen this behaviour, too, but it seems to be due to stale krb5cc_* files
left after an unclean logout (e.g. user logged out by system reboot).
Otherwise, this module is working just fine on amd64. Please unmask this
package.

*** Bug 146449 has been marked as a duplicate of this bug. ***

It still does not work:

as75|21:06|1|>ssh shetach.chem.jyu.fi
Password: 
Last login: Wed May  9 00:04:58 2007 from as75.adsl.tnnet.fi
arno@shetach ~ $ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_45132)

arno@shetach ~ $ kinit
Password for arno@CC.JYU.FI: 
arno@shetach ~ $ klist
Ticket cache: FILE:/tmp/krb5cc_45132
Default principal: arno@CC.JYU.FI

Valid starting     Expires            Service principal
05/08/07 21:07:02  05/09/07 07:07:02  krbtgt/CC.JYU.FI@CC.JYU.FI
        renew until 05/08/07 21:07:02
arno@shetach ~ $ 

(In reply to comment #9)
> It still does not work:

There are many things that can prevent the OpenSSH/krb5 combo from working. 
What I currently use is pam_krb5-3.5 from eyrie.org (attached).  Its only
problem is that it provides no AFS support; when coupled with pam-afs-session,
this isn't an issue.

Created an attachment (id=118608) [details]
pam_krb5-3.5.ebuild

Use 3.9; closing this.