patch attached. Based on cifs-util-6.4
Feature: Check /etc/krb5.conf for default_ccache_name. This patch will allow users to store Kerberos tickets on a shared drive. HPC clusters run jobs on behalf of users. The cluster effectively functions as a single compute resource. Jobs that require Kerberos keys will be able to access keys from a common shared drive defined by krb5.conf.
On 3/24/16, 9:50 AM, "Jeff Layton" <jlayton@xxxxxxxxx> wrote:
>On Thu, 24 Mar 2016 15:46:30 +0000
>"Dey, John F" <jfdey@xxxxxxxxxxxxx> wrote:
>
>> thanks for your reply. I’ve already written the code and it seems to work fine at our shop. I will request a pull request for the 6.5 release. below is a summary of what I’ve implemented. I only check the krb5.conf if no credentials are found in /run and /tmp locations.
>>
>> #define CIFS_DEFAULT_KRB5_KEYTAB "/etc/krb5.keytab"
>> #define CIFS_DEFAULT_KRB5_CONF "/etc/krb5.conf"
>> #define CIFS_CCACHE_CONF "default_ccache_name"
>>
>>
>
>Great! Please send patches instead of a pull request, and cc the
>linux-cifs mailing list. Others may want to review them as well.
>
>Thanks,
>Jeff
>
>>
>> /*
>> * read /etc/krb5.conf and
>> * if found return default_ccache_name
>> * else return NULL
>> */
>> static char* krb5conf_cc_name_path(char* krb5_conf_file);
>>
>> main()
>> {
>> ...
>> ccdir = resolve_krb5_dir(CIFS_DEFAULT_KRB5_USER_DIR, uid);
>> if (ccdir != NULL)
>> find_krb5_cc(ccdir, uid, &best_cache, &best_time);
>> ccname = find_krb5_cc(CIFS_DEFAULT_KRB5_DIR, uid, &best_cache, &best_time);
>> if (ccname == NULL) {
>> ccdir = krb5conf_cc_name_path(CIFS_KRB5_CONF);
>> ccname = find_krb5_cc(ccdir, uid, &best_cache, &best_time);
>> }
>> ...
>> }
>>
>>
>>
>>
>>
>>
>>
>> On 3/24/16, 8:24 AM, "Jeff Layton" <jlayton@xxxxxxxxx> wrote:
>>
>> >On Mon, 21 Mar 2016 17:37:35 +0000
>> >"Dey, John F" <jfdey@xxxxxxxxxxxxx> wrote:
>> >
>> >> Jeff,
>> >>
>> >> I am setting krb5.conf default_ccache_name = (shared mount point). The MIT krb5 routines work fine with the shared drive, but cifs.upcall is not reading the /etc/krb5.conf file to find the new location. Default search locations seem to be hard-coded into cifs.upcall.
>> >>
>> >> I am using Ubuntu 14.04 cifs-utils 6.0. I have also check Ubuntu 16.04 with cifs-util 6.5.
>> >>
>> >> In 2009 you had a patch to read the krb5CCNAME environment variable, this patch has since been removed. Setting the default path in krb5.conf seems to solve a lot of problems but cifs.upcall is not checking that location. Is there a reason why the krb5.conf is not checked?
>> >>
>> >> WHY are we doing this? We run a large linux cluster. Users interact with a set of head nodes. When users login to the headnotes their krb5 ticket is updated. From head nodes users can run jobs on the Linux cluster. The cluster nodes do not have updated tickets so users jobs fail. So we would like to use a shared drive for the tickets so that all the cluster nodes have an updated ticket.
>> >>
>> >> Thanks
>> >>
>> >> John Dey
>> >> Jidey@xxxxxxxxxxxxx
>> >> John@xxxxxxxxxxx
>> >>
>> >>
>> >>
>> >
>> >(cc'ing linux-cifs mailing list)
>> >
>> >Hmm, it's been so long since I looked at that code, I've forgotten how
>> >it works. Let's see...
>> >
>> > ccdir = resolve_krb5_dir(CIFS_DEFAULT_KRB5_USER_DIR, uid);
>> > if (ccdir != NULL)
>> > find_krb5_cc(ccdir, uid, &best_cache, &best_time);
>> > ccname = find_krb5_cc(CIFS_DEFAULT_KRB5_DIR, uid, &best_cache,
>> > &best_time);
>> >
>> >
>> >...and those CIFS_DEFAULT_* macros are:
>> >
>> >#define CIFS_DEFAULT_KRB5_DIR "/tmp"
>> >#define CIFS_DEFAULT_KRB5_USER_DIR "/run/user/%U"
>> >
>> >So yeah, it does seem to be hardcoded. Why was it written that way?
>> >ISTR that older versions of krb5 libs made it hard to get to that
>> >variable from the config file, but maybe I'm remembering wrong.
>> >
>> >It probably wouldn't be too hard to fix, but you'd have to dig into the
>> >krb5 library API. I doubt I'll have time to do that anytime soon. If
>> >you or your OS vendor wants to propose some patches however, I'd be
>> >happy to review (and eventually) merge them.
>> >
>> >Cheers,
>> >--
>> >Jeff Layton <jlayton@xxxxxxxxx>
>
>
>--
>Jeff Layton <jlayton@xxxxxxxxx>
Attachment:
cifs.upcall.patch
Description: cifs.upcall.patch
