Re: Solaris 10, secure nfs, permission denied - Kerberos

This is a discussion on Re: Solaris 10, secure nfs, permission denied - Kerberos ; > In general it looks like it should be working. Can you do the > > sudo share -F nfs -o sec=krb5,rw=crete:barnowl /usr > sudo mount -F nfs -o sec=krb5 barnowl:/usr /mnt /:barnowl> sudo share -F nfs -o sec=krb5,rw=crete:barnowl /usr ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Solaris 10, secure nfs, permission denied

  1. Re: Solaris 10, secure nfs, permission denied

    > In general it looks like it should be working. Can you do the
    >
    > sudo share -F nfs -o sec=krb5,rw=crete:barnowl /usr
    > sudo mount -F nfs -o sec=krb5 barnowl:/usr /mnt


    /:barnowl> sudo share -F nfs -o sec=krb5,rw=crete:barnowl /usr
    /:barnowl> sudo mount -F nfs -o sec=krb5 barnowl:/usr /mnt
    nfs mount: mount: /mnt: Permission denied
    /:barnowl>

    May 19 09:58:28 fookdc.mitre.org krb5kdc[11077](info): AS_REQ (5 etypes
    {17 16 23 3 1}) 129.83.10.149: CLIENT_NOT_FOUND:
    root/barnowl.mitre.org@RCF.MITRE.ORG for
    krbtgt/RCF.MITRE.ORG@RCF.MITRE.ORG, Client not found in Kerberos database
    May 19 09:58:28 fookdc.mitre.org krb5kdc[11077](info): AS_REQ (5 etypes
    {17 16 23 3 1}) 129.83.10.149: ISSUE: authtime 1211205508, etypes
    {rep=16 tkt=16 ses=1 6}, host/barnowl.mitre.org@RCF.MITRE.ORG for
    krbtgt/RCF.MITRE.ORG@RCF.MITRE.ORG

    > while on barnowl? Note, make sure nothing is mounted on /mnt first of
    > course. If that doesn't work can you try using an actually root session
    > and run the mount without sudo (which is not a native Solaris command).
    > If it works without sudo, try that on crete.


    Nothing is mounted on /mnt

    barnowl# mount -F nfs -o sec=krb5 barnowl:/usr /mnt
    nfs mount: mount: /mnt: Permission denied
    barnowl#

    > Also, what variant of krb are you using on crete? I ask because the
    > klist output on that system shows krb v4 info which the native Solaris
    > krb knows nothing about. While I don't think this is causing the
    > problem with the mount command one should be careful about mixing use of
    > krb variants on a system.


    I don't think it's relevant either. I considered it last
    week while I was trying to solve this problem and disregarded
    it.

    To answer your specific question, MIT Kerberos 1.6.x is installed
    in /usr/rcf-krb5/bin and is favored PATH-wise.

    >> ==== Basic NFS works ============================================
    >>
    >> ~:barnowl> sudo share -F nfs -o rw=crete /var/sadm
    >>
    >> ~:crete> sudo mount -F nfs barnowl:/var/sadm /mnt
    >> ~:crete> sudo umount /mnt
    >>
    >> ~:barnowl> sudo unshare /var/sadm
    >> ~:barnowl>
    >>
    >> ==== Basic krb5 auth works, FWIW ================================
    >>
    >> ~:crete> /usr/bin/klist
    >> Ticket cache: FILE:/tmp/krb5cc_26560
    >> Default principal: jblaine@RCF.MITRE.ORG
    >>
    >> Valid starting Expires Service principal
    >> 05/15/08 20:07:07 05/22/08 20:07:07 krbtgt/RCF.MITRE.ORG@RCF.MITRE.ORG
    >> renew until 05/22/08 20:07:07
    >> ~:crete>
    >>
    >> ==== The failing NFSv4 with krb5 ================================
    >>
    >> SERVER
    >> ------
    >>
    >> ~:barnowl> sudo klist -e -k /etc/krb5/krb5.keytab | grep barnowl
    >> 12 host/barnowl.mitre.org@RCF.MITRE.ORG (Triple DES cbc mode with
    >> HMAC/sha1)
    >> 12 host/barnowl.mitre.org@RCF.MITRE.ORG (DES cbc mode with CRC-32)
    >> 6 nfs/barnowl.mitre.org@RCF.MITRE.ORG (DES cbc mode with CRC-32)
    >> ~:barnowl>
    >>
    >> ~:barnowl> grep krb5 /etc/nfssec.conf
    >> krb5 390003 kerberos_v5 default - # RPCSEC_GSS
    >> krb5i 390004 kerberos_v5 default integrity # RPCSEC_GSS
    >> krb5p 390005 kerberos_v5 default privacy # RPCSEC_GSS
    >> ~:barnowl>
    >>
    >> ~:barnowl> sudo svcadm restart network/rpc/gss
    >> ~:barnowl>
    >>
    >> ~:barnowl> svcs -x nfs/server
    >> svc:/network/nfs/server:default (NFS server)
    >> State: online since May 15, 2008 8:06:05 PM EDT
    >> See: nfsd(1M)
    >> See: /var/svc/log/network-nfs-server:default.log
    >> Impact: None.
    >> ~:barnowl>
    >>
    >> ~:barnowl> sudo share
    >> - /usr sec=krb5,rw=crete ""
    >> ~:barnowl>
    >>
    >> CLIENT
    >> ------
    >>
    >> ~:crete> sudo klist -e -k /etc/krb5/krb5.keytab | grep crete
    >> 5 nfs/crete.mitre.org@RCF.MITRE.ORG (DES cbc mode with CRC-32)
    >> 6 host/crete.mitre.org@RCF.MITRE.ORG (DES cbc mode with CRC-32)
    >> ~:crete>
    >>
    >> ~:crete> grep krb5 /etc/nfssec.conf
    >> krb5 390003 kerberos_v5 default - # RPCSEC_GSS
    >> krb5i 390004 kerberos_v5 default integrity # RPCSEC_GSS
    >> krb5p 390005 kerberos_v5 default privacy # RPCSEC_GSS
    >> ~:crete>
    >>
    >> ~:crete> sudo svcadm restart network/rpc/gss
    >> ~:crete>
    >>
    >> ~:crete> sudo kdestroy
    >> ~:crete> sudo mount -F nfs -o sec=krb5 barnowl:/usr /mnt
    >> nfs mount: mount: /mnt: Permission denied
    >> ~:crete> sudo klist
    >> Ticket cache: FILE:/tmp/krb5cc_0
    >> Default principal: host/crete.mitre.org@RCF.MITRE.ORG
    >>
    >> Valid starting Expires Service principal
    >> 05/15/08 20:49:34 05/16/08 06:49:34 krbtgt/RCF.MITRE.ORG@RCF.MITRE.ORG
    >> 05/15/08 20:49:34 05/16/08 06:49:34 nfs/barnowl.mitre.org@RCF.MITRE.ORG
    >>
    >>
    >> Kerberos 4 ticket cache: /tmp/tkt0
    >> klist: You have no tickets cached

    >
    >> ~:crete>
    >>
    >> ON THE KDC WHEN THE MOUNT FAILS
    >> -------------------------------
    >>
    >> May 15 20:49:34 fookdc.mitre.org krb5kdc[11077](info): AS_REQ (5
    >> etypes {17 16 23 3 1}) 128.29.72.73: CLIENT_NOT_FOUND:
    >> root/crete.mitre.org@RCF.MITRE.ORG for
    >> krbtgt/RCF.MITRE.ORG@RCF.MITRE.ORG, Client not found in Kerberos database
    >> May 15 20:49:34 fookdc.mitre.org krb5kdc[11077](info): DISPATCH:
    >> repeated (retransmitted?) request from 128.29.72.73, resending previous
    >> response
    >> May 15 20:49:34 fookdc.mitre.org krb5kdc[11077](info): AS_REQ (5
    >> etypes {17 16 23 3 1}) 128.29.72.73: ISSUE: authtime 1210898974, etypes
    >> {rep=3 tkt=16 ses=16}, host/crete.mitre.org@RCF.MITRE.ORG for
    >> krbtgt/RCF.MITRE.ORG@RCF.MITRE.ORG
    >> May 15 20:49:34 fookdc.mitre.org krb5kdc[11077](info): TGS_REQ (5
    >> etypes {17 16 23 3 1}) 128.29.72.73: ISSUE: authtime 1210898974, etypes
    >> {rep=16 tkt=1 ses=1}, host/crete.mitre.org@RCF.MITRE.ORG for
    >> nfs/barnowl.mitre.org@RCF.MITRE.ORG
    >> ________________________________________________
    >> Kerberos mailing list Kerberos@mit.edu
    >> https://mailman.mit.edu/mailman/listinfo/kerberos

    >


  2. Re: Solaris 10, secure nfs, permission denied


    According to the log below and your klist output you have not
    performed step 2a from the "How to Access a Kerberos Protected NFS
    File System as the root User" section here
    http://docs.sun.com/app/docs/doc/816...tup-148?a=view. It is also
    listed as an optional step 6b in the "How to Manually Configure a
    Kerberos Client" section on the same page. Hope this is helpful.
    Thanks.

    > May 19 09:58:28 fookdc.mitre.org krb5kdc[11077](info): AS_REQ (5 etypes
    > {17 16 23 3 1}) 129.83.10.149: CLIENT_NOT_FOUND:
    > root/barnowl.mitre....@RCF.MITRE.ORG for
    > krbtgt/RCF.MITRE....@RCF.MITRE.ORG, Client not found in Kerberos database
    > May 19 09:58:28 fookdc.mitre.org krb5kdc[11077](info): AS_REQ (5 etypes
    > {17 16 23 3 1}) 129.83.10.149: ISSUE: authtime 1211205508, etypes
    > {rep=16 tkt=16 ses=1 6}, host/barnowl.mitre....@RCF.MITRE.ORG for
    > krbtgt/RCF.MITRE....@RCF.MITRE.ORG



  3. Re: Solaris 10, secure nfs, permission denied

    On Mon, May 19, 2008 at 01:15:48PM -0700, Borislav_S wrote:
    >
    > According to the log below and your klist output you have not
    > performed step 2a from the "How to Access a Kerberos Protected NFS
    > File System as the root User" section here
    > http://docs.sun.com/app/docs/doc/816...tup-148?a=view. It is also
    > listed as an optional step 6b in the "How to Manually Configure a
    > Kerberos Client" section on the same page. Hope this is helpful.
    > Thanks.


    Creating a root principal is not needed for mounting a NFS share
    protected by krb. That is only needed if a user wants to access a NFS
    sec=krb5* share as root. In general it's better not to have a root
    principal unless there is a specific need. Note that Solaris krb will
    fall back to automatically acquiring a krb cred via the host/
    entry in /etc/krb5/krb5.keytab if it exists when it is determined that a
    krb cred is needed by root as is the case when doing a mount of a NFS
    sec=krb5* share.

    --
    Will Fiveash
    Sun Microsystems Inc.
    http://opensolaris.org/os/project/kerberos/

+ Reply to Thread