Bug 487439 - openssh ignores/overrides pam_krb5 ccache_dir setting
openssh ignores/overrides pam_krb5 ccache_dir setting
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openssh (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Petr Lautrbach
BaseOS QE
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-25 19:00 EST by James Ralston
Modified: 2012-04-20 14:59 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-20 14:59:50 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)
pam_krb5 debug syslog messages (7.13 KB, text/plain)
2009-03-09 17:39 EDT, James Ralston
no flags Details

  None (edit)
Description James Ralston 2009-02-25 19:00:22 EST
Here's an excerpt from our standard /etc/krb5.conf file:

[appdefaults]

pam = {
  EXAMPLE.ORG = {
    ccache_dir = /ccache
  }
}

The /ccache directory is a tiny tmpfs filesystem that is mounted mode 01333:

$ ls -lsad /ccache
0 d-wx-wx-wt 2 root root 40 Feb 25 17:16 /ccache

Locating the credential cache files in this directory offers an additional level of privacy over using /tmp (the default value for ccache_dir), because users cannot enumerate the directory contents to see who has credentials cached on the host.  Since the cache files are created via mkstemp() using a template of %d/krb5cc_%U_XXXXXXXXXX, guessing the names of cache files is extremely difficult.

With the above configuration on a RHEL 5Server host, and PAM on the host configured to use the pam_krb5 module, if I log in via any service EXCEPT openssh, the credential cache is properly located in /ccache. But if I login via openssh (which is by far the most frequent login method), the credential cache is located in /tmp:

$ ssh -o PreferredAuthentications=gssapi-with-mic -o GSSAPIDelegateCredentials=yes rhel5box.example.org 'echo $KRB5CCNAME'
FILE:/tmp/krb5cc_1000_evOyW24345

So, somehow, openssh overrides or ignores the ccache_dir setting.

As with bug 486256, Fedora 10 does the right thing: when I log into my Fedora 10 host via openssh with the same configuration, the credential cache is properly located in /ccache:

$ ssh -o PreferredAuthentications=gssapi-with-mic -o GSSAPIDelegateCredentials=yes f10box.example.org 'echo $KRB5CCNAME'
FILE:/ccache/krb5cc_4524_pnNKCc

RHEL5 packages:

openssh-4.3p2-29.el5.x86_64
pam-0.99.6.2-4.el5.x86_64
pam_krb5-2.2.14-10.x86_64

F10 packages:

openssh-5.1p1-3.fc10.x86_64
pam-1.0.2-2.fc10.x86_64
pam_krb5-2.3.2-1.fc10.x86_64
Comment 1 James Ralston 2009-03-06 12:55:58 EST
Cross-filed as Red Hat Service Request 1901382.
Comment 2 James Ralston 2009-03-06 17:21:39 EST
An update from bug 486256: if one also sets "use_shmem = sshd" in the "pam" section of [appdefaults], then keyboard-interactive authentication will obey the ccache_dir.

This makes no difference for gssapi-with-mic and password authentication, however; they use /tmp regardless of whether use_shmem is set.
Comment 3 Nalin Dahyabhai 2009-03-09 11:54:11 EDT
gssapi-with-mic I understand, as it doesn't go through PAM to acquire the forwarded credentials, so the PAM module isn't what's determining where the ccache ends up.  sshd would have to expose an option of its own to provide a way to control that behavior.  Password authentication, if "KerberosAuthentication" is enabled in the server, appears to be attempted outside of PAM first.

Can you set "debug = true" in the [appdefaults] "pam" section, modify /etc/syslog.conf so that debug messages are saved to a file ("*.* /var/log/debug" would do the trick), restart syslogd, attempt the login, and either paste or attach the log messages you get on the system that doesn't behave correctly, along with its sshd_config file?
Comment 4 James Ralston 2009-03-09 17:35:22 EDT
Ok, I figured out what is happening: when pam_krb5 runs for the account service, more recent pam_krb5 modules are actually copying the credentials from the stash file that sshd creates (see the log excerpt I'll attach momentarily).

Also, I was incorrect: both password and keyboard-interactive authentication obey the ccache_dir setting.

Here's the openssh code that creates the credential cache (in auth-krb5.c):

krb5_error_code
ssh_krb5_cc_gen(krb5_context ctx, krb5_ccache *ccache) {
        int tmpfd, ret;
        char ccname[40];
        mode_t old_umask;

        ret = snprintf(ccname, sizeof(ccname),
            "FILE:/tmp/krb5cc_%d_XXXXXXXXXX", geteuid());
        if (ret < 0 || (size_t)ret >= sizeof(ccname))
                return ENOMEM;

        old_umask = umask(0177);
        tmpfd = mkstemp(ccname + strlen("FILE:"));

Notice that the credential cache file is completely hardcoded.

I think the best solution here is for sshd to provide an option to change the location of the credential cache.  I'll write a patch to do so and see if upstream is willing to take it.
Comment 5 James Ralston 2009-03-09 17:39:16 EDT
Created attachment 334581 [details]
pam_krb5 debug syslog messages

This shows that recent versions of pam_krb5 copy the Kerberos credentials that sshd creates in /tmp to the location specified by ccache_dir and ccname_template.

(Look at the 10 lines or so following the "checking for externally-obtained v5 credentials" line.)
Comment 6 Nalin Dahyabhai 2009-03-09 17:47:15 EDT
(In reply to comment #4)
> Ok, I figured out what is happening: when pam_krb5 runs for the account
> service, more recent pam_krb5 modules are actually copying the credentials from
> the stash file that sshd creates (see the log excerpt I'll attach momentarily).

Oh, right.  We also turned on "external" by default for sshd at about the same time, so that it could use forwarded credentials to obtain AFS tokens (if you're using AFS, anyway).  I haven't looked lately, but sshd is still managing the ccache it creates in /tmp, and having pam_krb5 create another one doesn't cause that to stop happening.
Comment 7 Jan F. Chadima 2010-05-10 02:29:26 EDT
(In reply to comment #4)
> I think the best solution here is for sshd to provide an option to change the
> location of the credential cache.  I'll write a patch to do so and see if
> upstream is willing to take it.    
Have you written the patch, if so can you refer it in mindrot bz?
Comment 9 Jake Kodak 2012-04-20 14:59:50 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. After consideration, Red Hat does not plan to incorporate the suggested capability in a future release of RHEL 5. If you would like Red Hat to re-consider your feature request beyond RHEL 5, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

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