Bug 461041 - Feature Request: Enable kerberos5 support in coda
Feature Request: Enable kerberos5 support in coda
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: coda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-03 12:07 EDT by Neil Horman
Modified: 2008-09-13 10:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-13 10:13:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to enable coda building with krb5 support (1.13 KB, patch)
2008-09-03 12:11 EDT, Neil Horman
no flags Details | Diff

  None (edit)
Description Neil Horman 2008-09-03 12:07:15 EDT
Description of problem:
If you could please:
1) Add kerberos 5 support the coda packages
2) Add pam_kcoda to the package  (http://www.kernel.org/pub/linux/libs/pam/pre/modules/pam_kcoda-v0.4.tgz)

I'd like  to move my home directories out to coda, and to do that I'd like to auto-aquire coda toekns on login.  As I understand it, the proper procedure for doing that is to authenticate with kerberos and then use pam_kcoda to obtain coda tokens using the previously aquired kerberos tickets.

V
Comment 1 Neil Horman 2008-09-03 12:11:00 EDT
Created attachment 315659 [details]
patch to enable coda building with krb5 support

This is a patch for building coda with krb5 support.  The autoconf configure script seems to have a bug in which it doesn't detect krb5 properly (I think its assuming that it automatically gets linked in somehow).  At any rate, the patch above works around the problem.  The proper fix is of course to fix the autoconf script, but I absolutley stinnk at autoconf :).

Anywho, I've tested the above patch on my coda environment, and I am able to automatically obtain coda tokens using tickets granted by my kerberos 5 kdc server.

Thanks!
Comment 2 Hans de Goede 2008-09-03 14:02:13 EDT
Neil, John,

Good to see that some people are actually using my coda packages I created them for use in some lab exercises for the University where I no longer work. Creating them was quite a bit of work so I'm glad to see them used!

My co-maintainer Adam actually knows more about coda then me and also is in contact with upstream, so I hope he will join in the discussion here, Adam can you please give us your opinion on what I write below ?

When I first packaged coda I looked into enabling kerberos, but as far as I remember the kerberos support of the official coda code is not so good, or rather it is good quality, but it is limited in functionality, mostly in that it has certain expectations of how the kerberos realm is setup, for more see:
http://osdir.com/ml/file-systems.coda.general/2007-03/msg00037.html

Since coda is very modular only the coda clog binary needs replacing to plug in a diferent authentication mechanism and there is an (experimental) clog replacement called modular clog which is supposed to be better.

Now with all this said, I've no objections to enabling kerberos support as it is available in the standard coda packages, I just wanted you all to be aware that the kerberos support there is limited. And thanks for the patches!

Adam, I'll be away to Fudcon Brno the next couple of days, so if you have no objections against enabling the build-in kerberos support either feel free to commit the attached patches and do a new build. Actually if you want you can become the coda package owner (we can swap places if you still want me a \round as co-maintainer).
Comment 3 Neil Horman 2008-09-03 14:16:44 EDT
Thanks for looking into this Hans.  I've used AFS quite a bit, and always been interested in coda, but only recently have I had a chance to set up my own coda realm.

Regarding your thoughts above, the best answer I can give you is: I'm not sure. I've set up the standard krb5 server, configured a realm using the kerberos 5 howto (http://tldp.org/HOWTO/Kerberos-Infrastructure-HOWTO/), added principals for myself and my coda scm/auth server.  I patched the coda package with the patch above and rolled it out to my clients and server, and it works great.  If there are limitations, they are currently beyond my needs for them (my goal is to use pam_krb5 to automatically obtain kerberos tickets on login, then stack that with pam_kcoda to automatically authenticate me to coda without the need for an addional password validation).  That way I can have my home directory out on coda easily.  So far it all seems to be working quite well.

If you feel like there is a better way to integrate coda with kerberos to achieve that (and any other) goals, I'm more than happy to test them out.  Currently though, the built in kerberos support as described above fills my needs perfectly.

FWIW, one of my long term goals is to get involved at my sons elementary school and start rolling out coda there.  Heres hoping :)
Comment 4 Neil Horman 2008-09-03 15:22:35 EDT
Oops, sorry need to make one correction regarding my above comment.  While kerberos and clog work quite well and as I expect them too, pam_kcoda does have a bug which prevents it from automatically obtaining coda tokens.  They do a fork and redirect stdin/stdou incorectly, resulting in a failure .  I'll write a patch for it an attach it shortly.
Comment 5 Hans de Goede 2008-09-03 16:32:41 EDT
Oh, I forgot about the pam module, as that has a seperate upstream source, it really should be put in a seperate package.
Comment 6 Neil Horman 2008-09-03 16:47:49 EDT
copy that.  Then, unless you would prefer to do it yourself, I'll package it once I finish getting it working/clean it up and submit it for review .  Thanks!
Comment 7 Hans de Goede 2008-09-03 16:57:59 EDT
(In reply to comment #6)
> copy that.  Then, unless you would prefer to do it yourself, I'll package it
> once I finish getting it working/clean it up and submit it for review . 
> Thanks!

I've got no intentions of packaging it, so go ahead and package it.
Comment 8 Adam Goode 2008-09-03 22:43:29 EDT
Hey all,

I don't have much time right now, but I talked with Jan (Harkes) today and showed him this bug report. I'll write up a little more later (and definitely update the specfile), but the short of it is krb5 support went in before Coda had multi-realm support, so it is old and not tested by us at CMU.

The modular clog stuff is quite divorced from what upstream would like, so it would not go upstream without significant effort and redesign. Fortunately, it could be used alongside the standard clog since in both cases the goal is to acquire a Coda token that is passed along uninterpreted to the server.

In all cases, all the Coda server cares about is a valid token from the server. Jan would someday like to investigate getting rid of auth2 (the Coda auth server) and perhaps replacing it with a system based on OpenLDAP. Then you just SASL to the server and convince it to produce a Coda token for you.

Anyway, good luck with any deployments, and keep an eye on http://www.coda.cs.cmu.edu/trac
Comment 9 Neil Horman 2008-09-04 10:34:13 EDT
Using the modular clog stuff is fine with me, I can package it if need be.  As far as krb5 support and multi-realm usage is concerned though, As far as I know, our krb5 client only support one kerberos realm at a time, so even if coda supports multiple coda realms (which may authenticate to multiple krb5 realms), the krb5 client we have limits our support.  I'm probably mis-understanding the issue here, but it seems that multi-realm support in coda is limited by factors outside of coda anyway.
Comment 10 Adam Goode 2008-09-04 10:58:07 EDT
Modular clog I think would have to be patched to have different names. I don't know, you might even use the alternatives system at that point.

Both krb5 and coda have the notion of realms, in krb5 you can do cross-realm ACLs and such, but coda doesn't support that, instead it lets you acquire tickets from as many realms as you like. krb5 does let you acquire tickets from multiple realms, but it requires environment variable hackery that seems quite annoying. As far as I know, modular clog does these tricks to do its thing as well.

Basically the problem is: how do you get a coda token from a krb5 ticket? Right now it is sort of hardcoded to have your coda token match your krb5 principal name, but it would be nice to have some generality in the coda token generation mechanism.
Comment 11 Fedora Update System 2008-09-09 15:20:49 EDT
coda-6.9.4-0.2.rc2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/coda-6.9.4-0.2.rc2.fc9
Comment 12 Adam Goode 2008-09-09 23:39:47 EDT
Just a few comments:

I don't think you need to build require e2fsprogs-devel. That is automatically pulled in from krb5-devel.

Do you need to require krb5-libs? Isn't that automatic?

Also, the -I/usr/include/et is fixed in git upstream, so I'll put a note in the specfile to remove this eventually.
Comment 13 Neil Horman 2008-09-10 08:28:37 EDT
They may well be automatic, but I would prefer to include them explicitly, just in case that changes.

Thank you for noting the upstream fix, I'll be sure to remove it on the next update.
Comment 14 Fedora Update System 2008-09-11 13:13:57 EDT
coda-6.9.4-0.2.rc2.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Adam Goode 2008-09-12 15:57:29 EDT
This breaks non-krb5 authentication. :(

Now you have to say "clog -coda".

Shouldn't this have been pushed to testing first??

Can this be reverted, pushed to stable, and then worked on some more in testing?
Comment 16 Neil Horman 2008-09-12 16:19:16 EDT
you shouldn't have to run clog with the -coda option.  It works fine for me.  If I don't have krb5 tokens for my realm, then  it reports that to me and prompts for my coda auth server password, and gets me coda tokens that way.
Comment 17 Adam Goode 2008-09-12 16:47:26 EDT
My coda realm is coda.cs.cmu.edu but my krb5 realm is andrew.cmu.edu:


agoode@localhost ~ $ clog
username: agoode@coda.cs.cmu.edu
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Password for agoode@ANDREW.CMU.EDU: 
kinit(v5): Password incorrect while getting initial credentials
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Failed to get secret for MOZART.CODA.CS.CMU.EDU
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Password for agoode@ANDREW.CMU.EDU: 
kinit(v5): Password incorrect while getting initial credentials
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Failed to get secret for VERDI.CODA.CS.CMU.EDU
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Password for agoode@ANDREW.CMU.EDU: 
kinit(v5): Password incorrect while getting initial credentials
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Failed to get secret for MARAIS.CODA.CS.CMU.EDU
Invalid login (RPC2_FAIL (F)).
Comment 18 Adam Goode 2008-09-12 16:48:26 EDT
Alternately, if I provide the correct krb5 password each time:

agoode@localhost ~ $ clog 
username: agoode@coda.cs.cmu.edu
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Password for agoode@ANDREW.CMU.EDU: 
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Failed to get secret for MOZART.CODA.CS.CMU.EDU
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Password for agoode@ANDREW.CMU.EDU: 
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Failed to get secret for VERDI.CODA.CS.CMU.EDU
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Password for agoode@ANDREW.CMU.EDU: 
krb5.c: Server not found in Kerberos database while preparing AP_REQ
Failed to get secret for MARAIS.CODA.CS.CMU.EDU
Invalid login (RPC2_FAIL (F)).
Comment 19 Neil Horman 2008-09-12 18:27:26 EDT
alright, alright.  But I really don't want to revert support for krb5.  What if we patched clog so that -coda was the default mode of obtaining tickets?  That way the previous behavior would be the same, but we could still use krb5 if we want.  Perhaps we can even add a venus config option to override the default later?
Comment 20 Adam Goode 2008-09-12 23:38:17 EDT
The patch sounds like a great way forward, I think that would take care of things for now. I may have a little time in the next day or so to do it...
Comment 21 Neil Horman 2008-09-13 10:13:11 EDT
Fantastic, we're agreed then.  I've opened bz 462179 to track this (since the discussion in this bug doesn't relate, and we're keeping krb5 support on).  You're on the CC list, and thank you for offering to write the patch.  If you attach it there I'll check it in straight away.  Thanks again!

Note You need to log in before you can comment on or make changes to this bug.