https://bugzilla.novell.com/show_bug.cgi?id=743976 https://bugzilla.novell.com/show_bug.cgi?id=743976#c2 --- Comment #2 from lynn wilson 2012-01-29 15:50:43 UTC --- (In reply to comment #1)

Sorry, the workaround is not correct. I should say specify anongid=100 not gid=100 . It only works for editing existing files when gss/krb5 is used.

Summary: mount -t nfs4 hh3:/home /mnt -o sec=krb5 mounts ro mount -t nfs4 hh3/home /mnt mounts rw Bug? How can we have rw with gss security? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=743976 https://bugzilla.novell.com/show_bug.cgi?id=743976#c4 --- Comment #4 from lynn wilson 2012-01-30 14:20:53 UTC --- (In reply to comment #0)

User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

Mounting an nfs4 share using gss/krb5 only mounts read only despite rw being specified. However, a conventional mount without gss/krb5 maps fine.

I used Yast to set the gss security and the nfs4 domain.

/etc/fstab /home /export/home none rw,bind 0 0

/etc/exports /export gss/krb5(rw,fsid=0,insecure,no_subtree_check) /export/home gss/krb5(rw,nohide,insecure,no_subtree_check) /export *(rw,fsid=0,crossmnt,insecure,no_subtree_check,async) /export/home *(rw,insecure,no_subtree_check,async)

With this: mount -t nfs4 server:/home /mnt -o sec=krb5 A Kerberos authenticated user cannot write to the share under /mnt in his exported home directory.

With this: mount -t nfs4 server:/home /mnt he can. The gid is mapped correctly.

Adding this to /etc/exports fixes the problem: /export/home gss/krb5(rw,nohide,insecure,no_subtree_check,gid=100)

Should be anongid=100)

e.g. fqdn hh3.hh3.site, nfs4 domain CACTUS, user steve5 uid=300020, gid=100

/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

mount -t nfs4:/home /mnt -o sec=krb5

Kerberos: TGS-REQ HH3$@HH3.SITE from ipv4:192.168.1.3:45825 for nfs/hh3.hh3.site@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

user steve5 logs in: # su steve5 (passwd etc...) Kerberos: AS-REQ steve5@HH3.SITE from ipv4:192.168.1.3:50182 for krbtgt/HH3.SITE@HH3.SITE Kerberos: Client sent patypes: 149 Kerberos: Looking for PKINIT pa-data -- steve5@HH3.SITE Kerberos: Looking for ENC-TS pa-data -- steve5@HH3.SITE Kerberos: No preauth found, returning PREAUTH-REQUIRED -- steve5@HH3.SITE Kerberos: AS-REQ steve5@HH3.SITE from ipv4:192.168.1.3:44732 for krbtgt/HH3.SITE@HH3.SITE Kerberos: Client sent patypes: encrypted-timestamp, 149 Kerberos: Looking for PKINIT pa-data -- steve5@HH3.SITE Kerberos: Looking for ENC-TS pa-data -- steve5@HH3.SITE Kerberos: ENC-TS Pre-authentication succeeded -- steve5@HH3.SITE using arcfour-hmac-md5

steve5 goes to the share: # cd /mnt/CACTUS/steve5 Kerberos: TGS-REQ steve5@HH3.SITE from ipv4:192.168.1.3:43987 for nfs/hh3.hh3.site@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

_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

The nfs4 share is only writeable without the gss/krb5.

Workaround: add the gid to the export in /etc/exports: /export/home gss/krb5(rw,nohide,insecure,no_subtree_check,gid=100)

And then user steve5 can write to the share.

Reproducible: Always

Steps to Reproduce: 1.mount -t nfs4 server:/home /mnt -O sec=krb5 2.cd to the mount as an authenticated user 3.touch myfile.txt 4. Actual Results: touch: cannot touch `myfile.txt': Permission denied

Expected Results: the file myfile.txt is created

There are two ways to workaround this either by specifying a gid in /etc/exports or not using gss/krb5. Both are rather limiting.

As this is to do with security I hope you don't mind me marking this is Major. I'm sure that I've overlooked something simple with idmapd but I can't see what is preventing the rw on the share.

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=743976 https://bugzilla.novell.com/show_bug.cgi?id=743976#c6 --- Comment #6 from lynn wilson 2012-01-31 17:25:06 UTC --- I narrowed it down a bit. I made the same config on Ubuntu 11.10 and it works fine. The problem on 12.1 seems to be with /etc/idmapd.conf. If I specify the actual Domain=hh3.site (my domain) in /etc/idmapd.conf, I can mount the share, but get 'Permission denied' when trying to access it. If I specify anything else other than my actual domain (such as CACTUS in the above examples), I can mount the share and access it OK but with only read permissions. Ubuntu allows me to specify the actual Domain=hh3.site in /etc/idmapd.conf and I can mount and access the shares rw with or without sec=gss/krb5 On both openSUSE and Ubuntu, the Kerberos is working ok as local users without tickets get 'Permission denied' when trying to access the share, as in the case of openSUSE when the actual domain is specified in /etc/idmapd.conf I made a screenshot of so you can see how I tested it: http://linuxcostablanca.blogspot.com/2012/01/important-samba-4-update.html Thanks -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=743976 https://bugzilla.novell.com/show_bug.cgi?id=743976#c8 --- Comment #8 from lynn wilson 2012-02-01 08:45:49 UTC --- And rcnfsserver restart before testing. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.