2012-01-28 21:44 keltezéssel, steve írta: > On 28/01/12 20:29, Gémes Géza wrote: >> 2012-01-28 18:41 keltezéssel, steve írta: >>> On 28/01/12 12:21, steve wrote: >>>> On 28/01/12 11:03, Gémes Géza wrote: >>> Summary: >>> >>> 1. kerberized /etc/exports >>> /export gss/krb5(rw,fsid=0,insecure,no_subtree_check,async) >>> /export/home gss/krb5(rw,nohide,insecure,no_subtree_check,async) >>> then: >>> mount -t nfs4 hh3:/home /mnt -o sec=krb5 >>> no write access >>> >>> 2. conventional /etc/exports >>> /export *(rw,fsid=0,insecure,no_subtree_check,async) >>> /export/home *(rw,nohide,insecure,no_subtree_check,async) >>> then: >>> mount -t nfs4 hh3:/home /mnt >>> write access OK >>> >>> 3. kerberized variation on /etc/exports >>> /export >>> *(rw,fsid=0,crossmnt,insecure,no_subtree_check,async,sec=krb5) >>> /export/home *(rw,insecure,no_subtree_check,async,sec=krb5) >>> then: >>> mount -t nfs4 hh3:/home /mnt -o sec=krb5 >>> no write access >>> >>> I have tried all combos of crossmnt and nohide >>> >>> idmapd seems to be mapping correctly and id<user> gives what getent >>> gives >>> >>> Any ideas? Why does the kerberized mount not allow rw access? >>> Steve >>> >>> Geza, do you think it's worth sticking this on samba technical? >> To me it seems an nfs4 related problem so no samba-technical is not the >> right place to ask >> In the meantime please tell us a little more about your environment: >> pam config >> idmapd config >> klist (of user) right after login, before trying to do anything on nfs >> and after (e.g an ls) >> >> I'm not an nfs4 expert myself, but before migration (a few years ago) to >> openafs I've had a working nfs4 gss/krb5 setup (it just kernel panic-ed >> every other day, until I've got fed up and migrated away from it) maybe >> I can remember. >> >> Regards >> >> Geza > Hi again > > The share mounts rw conventionally but olnt ro when exported gss/krb5 > Here is the output and some files: > > /etc/pam.d/common-auth (the other pam files are OK and pam is working) > auth required pam_env.so > auth optional pam_gnome_keyring.so > auth sufficient pam_unix2.so > auth sufficient pam_krb5.so use_first_pass > auth required pam_deny.so > > /etc/idmapd.conf > [General] > Verbosity=0 > Pipefs-Directory=/var/lib/nfs/rpc_pipefs > Domain=CACTUS > [Mapping] > Nobody-User=nobody > Nobody-Group=nobody > idmapd seems to be working fine. Mappings are perfect client/server > Here is some output, which looks OK except for the mount being read only. > > # mount -t nfs4:/home /mnt -o sec=krb5 > produces a lot of activity in Samba 4 including: > Kerberos: TGS-REQ HH3$@HH3.SITE from ipv4:192.168.1.3:45825 for > nfs/hh3.hh3.s...@hh3.site [canonicalize, renewable] > Kerberos: TGS-REQ authtime: 2012-01-28T21:16:16 starttime: > 2012-01-28T21:16:16 endtime: 2012-01-29T07:16:16 renew till: > 2012-01-29T21:16:16 > > nd a ticket cache appears called krb5cc_machine_HH3.SITE > and > klist krb5cc_machine_HH3.SITE > Ticket cache: FILE:krb5cc_machine_HH3.SITE > Default principal: HH3$@HH3.SITE > Valid starting Expires Service principal > 01/28/12 18:57:25 01/29/12 04:57:25 krbtgt/hh3.s...@hh3.site > renew until 01/29/12 18:57:25 > 01/28/12 18:57:25 01/29/12 04:57:25 nfs/hh3.hh3.s...@hh3.site > renew until 01/29/12 18:57:25 > > I got some rpc stuff during the mount: > # rpc.gssd -vvvf > beginning poll > dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc > dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc > dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc > dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc > dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc > handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt13) > handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' > handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt13) > process_krb5_upcall: service is '<null>' > Full hostname for 'hh3.hh3.site' is 'hh3.hh3.site' > Full hostname for 'hh3.hh3.site' is 'hh3.hh3.site' > Success getting keytab entry for 'HH3$@HH3.SITE' > Successfully obtained machine credentials for principal > 'HH3$@HH3.SITE' stored in ccache 'FILE:/tmp/krb5cc_machine_HH3.SITE' > INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_HH3.SITE' are good > until 1327817776 > using FILE:/tmp/krb5cc_machine_HH3.SITE as credentials cache for > machine creds > using environment variable to select krb5 ccache > FILE:/tmp/krb5cc_machine_HH3.SITE > creating context using fsuid 0 (save_uid 0) > creating tcp client for server hh3.hh3.site > DEBUG: port already set to 2049 > creating context with server n...@hh3.hh3.site > 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 > dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc > dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc > dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc > destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt14 > > user steve5 logs in: > # su steve5 > (passwd etc...) > Kerberos: AS-REQ ste...@hh3.site from ipv4:192.168.1.3:50182 for > krbtgt/hh3.s...@hh3.site > Kerberos: Client sent patypes: 149 > Kerberos: Looking for PKINIT pa-data -- ste...@hh3.site > Kerberos: Looking for ENC-TS pa-data -- ste...@hh3.site > Kerberos: No preauth found, returning PREAUTH-REQUIRED -- ste...@hh3.site > Kerberos: AS-REQ ste...@hh3.site from ipv4:192.168.1.3:44732 for > krbtgt/hh3.s...@hh3.site > Kerberos: Client sent patypes: encrypted-timestamp, 149 > Kerberos: Looking for PKINIT pa-data -- ste...@hh3.site > Kerberos: Looking for ENC-TS pa-data -- ste...@hh3.site > Kerberos: ENC-TS Pre-authentication succeeded -- ste...@hh3.site using > arcfour-hmac-md5 > > steve5 goes to the share: > # cd /mnt/CACTUS/steve5 > Kerberos: TGS-REQ ste...@hh3.site from ipv4:192.168.1.3:43987 for > nfs/hh3.hh3.s...@hh3.site [canonicalize, renewable, forwardable] > Kerberos: TGS-REQ authtime: 2012-01-28T21:21:50 starttime: > 2012-01-28T21:23:29 endtime: 2012-01-29T07:21:50 renew till: > 2012-01-29T21:21:50 > > idmappings under the mount seem OK: > steve5@hh3:/mnt/CACTUS/steve5> ls -la > total 220 > drwxr-xr-x 27 steve5 users 4096 Jan 28 21:21 . > drwxr-xr-x 9 root root 4096 Jan 12 09:05 .. > -rwxr-xr-x 1 steve5 users 2331 Jan 28 19:11 .bash_history > -rwxr-xr-x 1 steve5 users 0 Jan 8 12:59 c > drwxr-xr-x 5 steve5 users 4096 Jan 8 15:10 .cache > drwxr-xr-x 11 steve5 users 4096 Jan 12 08:17 .config > drwxr-xr-x 3 steve5 users 4096 Jan 8 10:31 .dbus > drwxr-xr-x 2 steve5 users 4096 Jan 8 19:28 Desktop > -rwxr-xr-x 1 steve5 users 23 Jan 8 10:31 .dmrc > drwxr-xr-x 2 steve5 users 4096 Jan 8 10:31 Documents > drwxr-xr-x 2 steve5 users 4096 Jan 8 10:31 Downloads > -rwxr-xr-x 1 steve5 users 16 Jan 8 10:32 .esd_auth > drwxr-xr-x 2 steve5 users 4096 Jan 9 13:41 .fontconfig > drwxr-xr-x 3 steve5 users 4096 Jan 26 13:29 .gconf > drwxr-xr-x 3 steve5 users 4096 Jan 8 10:31 .gnome2 > drwxr-xr-x 2 steve5 users 4096 Jan 12 09:24 .gstreamer-0.10 > -rwxr-xr-x 1 steve5 users 177 Jan 26 13:29 .gtk-bookmarks > -rwxr-xr-x 1 steve5 users 341 Jan 9 13:42 .gtkrc-2.0 > drwxr-xr-x 2 steve5 users 4096 Jan 8 10:31 .gvfs > -rwxr-xr-x 1 steve5 users 122 Jan 12 09:54 hello5.txt > -rwxr-xr-x 1 steve5 users 2142 Jan 26 13:29 .ICEauthority > -rwxr-xr-x 1 steve5 users 314 Jan 28 21:26 .joe_state > drwxr-xr-x 3 steve5 users 4096 Jan 8 15:02 .kde4 > and: > steve5@hh3:/mnt/CACTUS/steve5> id > uid=3000020(steve5) gid=100(users) groups=100(users) > This checks OK with: > steve5@hh3:/mnt/CACTUS/steve5> wbinfo -i steve5 > CACTUS\steve5:*:3000020:100:steve5:/home/CACTUS/steve5:/bin/bash > Just to be sure: > steve5@hh3:/mnt/CACTUS/steve5> whoami > steve5 > _BUT_ > steve5@hh3:/mnt/CACTUS/steve5> touch myfile.txt > touch: cannot touch `myfile.txt': Permission denied > So we go back to the actual home folder: > steve5@hh3:/mnt/CACTUS/steve5> cd /home/CACTUS/steve5 > steve5@hh3:~> touch myfile.txt > steve5@hh3:~> ls -la myfile.txt > -rw-r--r-- 1 steve5 users 0 Jan 28 21:31 myfile.txt > And there is rw access! > > As the nfs4 is writeable without the krb5, that's why I thought it may > be related to the S4 Kerbreros. > Thanks for your patience, > Steve > Unfortunately I can't be of real help here (I don't remember anything similar from when I was using nfs4 with krb5) and it seems to be very nfs4 specific, the kerberos (samba4) part has done its job (obtaining machine ticket at mount time, and user ticket when you cd-ed into the mount. What goes on from then is nfs4s own business :-( . I would suggest to ask for help at (I don't know if there is one :-( ) a nfs4 mailing list/forum.
Good Luck! Regards Geza -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba