• Kerberos ksu not working with NFSv4 mount sec=krb5

    From Jason Keltz@21:1/5 to All on Sat May 22 14:22:08 2021
    Hi.

    I'm unable to get ksu working wth krb5 NFSv4, and can't quite figure out
    why.

    I am logged into a RHEL7 system as a user "jas" (uid 1004) with working Kerberos (Samba AD implementation).

    I want to switch from user jas to user tdb (uid 1011) using ksu.

    I set up a .k5login file in tdb account containing jas@AD.EECS.YORKU.CA

    If tdb home directory is mounted with sec=sys, as jas I can "ksu tdb"
    and it works every time.

    If tdb home directory is mounted with sec=krb5, ksu wants me to enter  a password.

    (Note that as jas I can still cat ~tdb/.k5login).

    KRB5CCNAME is FILE:/tmp/krb5cc_1004

    rpc.gssd -vvv returns:

    handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 '
    (nfs/clnt0)
    krb5_not_machine_creds: uid 1011 tgtname (null)
    ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE
    (Unspecified GSS failure.  Minor code may provide more information) - No Kerberos credentials available: Credentials cache permissions incorrect (filename: /tmp/krb5cc_1004)
    looking for client creds with uid 1011 for server sea.eecs.yorku.ca
    in /tmp
    CC '/tmp/krb5cc_1004' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_1004' owned by 1004, not 1011
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with
    preferred realm 'AD.EECS.YORKU.CA'
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
    CC '/tmp/krb5cc_0' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_0' owned by 0, not 1011
    looking for client creds with uid 1011 for server sea.eecs.yorku.ca
    in /run/user/%U
    Error doing scandir on directory '/run/user/1011': No such file or
    directory
    doing error downcall

    handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 '
    (nfs/clnt0)
    krb5_not_machine_creds: uid 1011 tgtname (null)
    ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE
    (Unspecified GSS failure.  Minor code may provide more information) - No Kerberos credentials available: Credentials cache permissions incorrect (filename: /tmp/krb5cc_1004)
    looking for client creds with uid 1011 for server sea.eecs.yorku.ca
    in /tmp
    CC '/tmp/krb5cc_1004' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_1004' owned by 1004, not 1011
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with
    preferred realm 'AD.EECS.YORKU.CA'
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
    CC '/tmp/krb5cc_0' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_0' owned by 0, not 1011
    looking for client creds with uid 1011 for server sea.eecs.yorku.ca
    in /run/user/%U
    Error doing scandir on directory '/run/user/1011': No such file or
    directory
    doing error downcall

    If I actually enter the password then /tmp/krb5cc_1011 shows up, and
    everything works.

    handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 '
    (nfs/clnt0)
    krb5_not_machine_creds: uid 1011 tgtname (null)
    ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE
    (Unspecified GSS failure.  Minor code may provide more information) - No Kerberos credentials available: Credentials cache permissions incorrect (filename: /tmp/krb5cc_1004)
    looking for client creds with uid 1011 for server sea.eecs.yorku.ca
    in /tmp
    CC '/tmp/krb5cc_1004' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_1004' owned by 1004, not 1011
    CC '/tmp/krb5cc_1011.9bpz551G' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC 'FILE:/tmp/krb5cc_1011.9bpz551G'(tdb@AD.EECS.YORKU.CA) passed all
    checks and has mtime of 1621645808
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with
    preferred realm 'AD.EECS.YORKU.CA'
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
    CC '/tmp/krb5cc_0' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_0' owned by 0, not 1011
    using FILE:/tmp/krb5cc_1011.9bpz551G as credentials cache for client
    with uid 1011 for server sea.eecs.yorku.ca
    using gss_krb5_ccache_name to select krb5 ccache
    FILE:/tmp/krb5cc_1011.9bpz551G
    creating tcp client for server sea.eecs.yorku.ca
    DEBUG: port already set to 2049
    creating context with server nfs@sea.eecs.yorku.ca
    DEBUG: serialize_krb5_ctx: lucid version!
    prepare_krb5_rfc4121_buffer: protocol 1
    prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 doing downcall: lifetime_rec=36000 acceptor=nfs@sea.eecs.yorku.ca

    Is ksu just verifying that I'm a valid kerberos user, and that a switch
    can be made to the new uid, then changing the uid with setuid only, in
    which case Kerberos NFS won't work,  or, is it supposed to import the
    ticket for destination user as well?

    If I enter the password when prompted, I can write files as the
    destination user tdb, but I don't want to enter a password.

    As a side note, if I set an ACL on the source users /tmp/krb5cc_1004
    file to allow the destination user (1011) to read it (which I know is incorrect), then the ksu "works" successfully, but of course the
    destination user can't write into the home directory anyway since the
    principal isn't present.  It's not clear if this is a ksu issue, or
    rpc.gssd and if this is fixable on my end or not.

    Jason.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Benjamin Kaduk@21:1/5 to Jason Keltz on Sun May 30 17:15:43 2021
    Copy: kerberos@mit.edu

    On Sat, May 22, 2021 at 02:22:08PM -0400, Jason Keltz wrote:
    Hi.

    I'm unable to get ksu working wth krb5 NFSv4, and can't quite figure out
    why.

    I am logged into a RHEL7 system as a user "jas" (uid 1004) with working Kerberos (Samba AD implementation).

    I want to switch from user jas to user tdb (uid 1011) using ksu.

    I set up a .k5login file in tdb account containing jas@AD.EECS.YORKU.CA

    If tdb home directory is mounted with sec=sys, as jas I can "ksu tdb"
    and it works every time.

    If tdb home directory is mounted with sec=krb5, ksu wants me to enter a password.

    (Note that as jas I can still cat ~tdb/.k5login).

    KRB5CCNAME is FILE:/tmp/krb5cc_1004

    rpc.gssd -vvv returns:

    handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 '
    (nfs/clnt0)
    krb5_not_machine_creds: uid 1011 tgtname (null)
    ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE
    (Unspecified GSS failure. Minor code may provide more information) - No Kerberos credentials available: Credentials cache permissions incorrect (filename: /tmp/krb5cc_1004)

    This seems to say that setuid() succeeded, and now rpc.gssd is looking
    around in /tmp/ for a credentials cache that has tickets that can
    authenticate to NFS for the current user. It seems that it's looking at
    the krb5cc file from jas, that is owned by jas, and seeing that the
    permissions don't match the (now-)expected tdb user as owner.


    looking for client creds with uid 1011 for server sea.eecs.yorku.ca
    in /tmp
    CC '/tmp/krb5cc_1004' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_1004' owned by 1004, not 1011
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with
    preferred realm 'AD.EECS.YORKU.CA'
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
    CC '/tmp/krb5cc_0' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_0' owned by 0, not 1011
    looking for client creds with uid 1011 for server sea.eecs.yorku.ca
    in /run/user/%U
    Error doing scandir on directory '/run/user/1011': No such file or
    directory
    doing error downcall

    handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 '
    (nfs/clnt0)
    krb5_not_machine_creds: uid 1011 tgtname (null)
    ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE
    (Unspecified GSS failure. Minor code may provide more information) - No Kerberos credentials available: Credentials cache permissions incorrect (filename: /tmp/krb5cc_1004)
    looking for client creds with uid 1011 for server sea.eecs.yorku.ca
    in /tmp
    CC '/tmp/krb5cc_1004' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_1004' owned by 1004, not 1011
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with
    preferred realm 'AD.EECS.YORKU.CA'
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
    CC '/tmp/krb5cc_0' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_0' owned by 0, not 1011
    looking for client creds with uid 1011 for server sea.eecs.yorku.ca
    in /run/user/%U
    Error doing scandir on directory '/run/user/1011': No such file or
    directory
    doing error downcall

    If I actually enter the password then /tmp/krb5cc_1011 shows up, and everything works.

    handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 '
    (nfs/clnt0)
    krb5_not_machine_creds: uid 1011 tgtname (null)
    ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE
    (Unspecified GSS failure. Minor code may provide more information) - No Kerberos credentials available: Credentials cache permissions incorrect (filename: /tmp/krb5cc_1004)
    looking for client creds with uid 1011 for server sea.eecs.yorku.ca
    in /tmp
    CC '/tmp/krb5cc_1004' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_1004' owned by 1004, not 1011
    CC '/tmp/krb5cc_1011.9bpz551G' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC 'FILE:/tmp/krb5cc_1011.9bpz551G'(tdb@AD.EECS.YORKU.CA) passed all
    checks and has mtime of 1621645808
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with
    preferred realm 'AD.EECS.YORKU.CA'
    CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
    CC '/tmp/krb5cc_0' being considered, with preferred realm
    'AD.EECS.YORKU.CA'
    CC '/tmp/krb5cc_0' owned by 0, not 1011
    using FILE:/tmp/krb5cc_1011.9bpz551G as credentials cache for client
    with uid 1011 for server sea.eecs.yorku.ca
    using gss_krb5_ccache_name to select krb5 ccache
    FILE:/tmp/krb5cc_1011.9bpz551G
    creating tcp client for server sea.eecs.yorku.ca
    DEBUG: port already set to 2049
    creating context with server nfs@sea.eecs.yorku.ca
    DEBUG: serialize_krb5_ctx: lucid version!
    prepare_krb5_rfc4121_buffer: protocol 1
    prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 doing downcall: lifetime_rec=36000 acceptor=nfs@sea.eecs.yorku.ca

    Is ksu just verifying that I'm a valid kerberos user, and that a switch
    can be made to the new uid, then changing the uid with setuid only, in
    which case Kerberos NFS won't work, or, is it supposed to import the
    ticket for destination user as well?

    [it looks like my understanding of what ksu does with credential caches is incorrect, so what I originally wrote here was incorrect and thus I deleted
    it. The man page discussion for -z, -Z, and maybe -k may be of interest.]

    If I enter the password when prompted, I can write files as the
    destination user tdb, but I don't want to enter a password.

    As a side note, if I set an ACL on the source users /tmp/krb5cc_1004
    file to allow the destination user (1011) to read it (which I know is incorrect), then the ksu "works" successfully, but of course the
    destination user can't write into the home directory anyway since the principal isn't present. It's not clear if this is a ksu issue, or
    rpc.gssd and if this is fixable on my end or not.

    It might be worth experimenting with not setting KRB5CCNAME, and
    investigating whether the pam configuration is the immediate trigger for
    the password prompt (I don't expect it to be coming from ksu itself), but I think this is not likely to be fixable easily. rpc.gssd seems to
    both be doing what it's intended to do, that just happens to not interact
    very well with what ksu does.

    -Ben

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)