[Bug 743976] New: nfs4 idmapd does not map gid correctly under gss/krb5
https://bugzilla.novell.com/show_bug.cgi?id=743976 https://bugzilla.novell.com/show_bug.cgi?id=743976#c0 Summary: nfs4 idmapd does not map gid correctly under gss/krb5 Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: i586 OS/Version: openSUSE 12.1 Status: NEW Severity: Major Priority: P5 - None Component: Network AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: lynn@steve-ss.com QAContact: qa@suse.de Found By: --- Blocker: --- 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 does not map the group correctly. 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) 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#c1 --- Comment #1 from lynn wilson <lynn@steve-ss.com> 2012-01-29 10:27:39 UTC --- 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. -- 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#c2 --- Comment #2 from lynn wilson <lynn@steve-ss.com> 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#c3 --- Comment #3 from lynn wilson <lynn@steve-ss.com> 2012-01-30 14:18:25 UTC --- Created an attachment (id=473266) --> (http://bugzilla.novell.com/attachment.cgi?id=473266) Output of rpc.gssd -vvvf -- 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 <lynn@steve-ss.com> 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#c5 --- Comment #5 from lynn wilson <lynn@steve-ss.com> 2012-01-31 09:05:51 UTC --- mount -t nfs4 hh3:/home /mnt with Kerberos Authenticated user steve5 (uid 3000021 gid 100) cd's to the mounted directory: rpc.idmapd -fvvvvvv rpc.idmapd: libnfsidmap: using domain: CACTUS rpc.idmapd: libnfsidmap: loaded plugin /usr/lib/libnfsidmap/nsswitch.so for method nsswitch rpc.idmapd: Expiration time is 600 seconds. rpc.idmapd: Opened /proc/net/rpc/nfs4.nametoid/channel rpc.idmapd: Opened /proc/net/rpc/nfs4.idtoname/channel rpc.idmapd: New client: b rpc.idmapd: Opened /var/lib/nfs/rpc_pipefs/nfs/clntb/idmap rpc.idmapd: New client: d rpc.idmapd: nfsdcb: authbuf=* authtype=user rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server : (user) id "0" -> name "root@CACTUS" rpc.idmapd: nfsdcb: authbuf=* authtype=user rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server : (user) id "1000" -> name "steve@CACTUS" rpc.idmapd: nfs4_name_to_uid: calling nsswitch->name_to_uid rpc.idmapd: nss_getpwnam: name 'steve@CACTUS' domain 'CACTUS': resulting localname 'steve' rpc.idmapd: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 rpc.idmapd: nfs4_name_to_uid: final return value is 0 rpc.idmapd: Client b: (user) name "steve@CACTUS" -> id "1000" rpc.idmapd: nfs4_name_to_gid: calling nsswitch->name_to_gid rpc.idmapd: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 rpc.idmapd: nfs4_name_to_gid: final return value is 0 rpc.idmapd: Client b: (group) name "users@CACTUS" -> id "100" rpc.idmapd: nfsdcb: authbuf=* authtype=user rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server : (user) id "3000021" -> name "steve5@CACTUS" uid:gid mappings correct, user can rw files. --- --- --- mount -t nfs4 hh3:/home /mnt -o sec=krb5 with Kerberos Authenticated user steve5 (uid 3000021 gid 100) cd's to the mounted directory: rpc.idmapd -fvvvvvv rpc.idmapd: libnfsidmap: using domain: CACTUS rpc.idmapd: libnfsidmap: loaded plugin /usr/lib/libnfsidmap/nsswitch.so for method nsswitch rpc.idmapd: Expiration time is 600 seconds. rpc.idmapd: Opened /proc/net/rpc/nfs4.nametoid/channel rpc.idmapd: Opened /proc/net/rpc/nfs4.idtoname/channel rpc.idmapd: New client: 8 rpc.idmapd: Opened /var/lib/nfs/rpc_pipefs/nfs/clnt8/idmap rpc.idmapd: New client: 9 rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server : (user) id "0" -> name "root@CACTUS" rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=group rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0 rpc.idmapd: nfs4_gid_to_name: final return value is 0 rpc.idmapd: Server : (group) id "0" -> name "root@CACTUS" rpc.idmapd: New client: a [warn] event_del: event has no event_base set. rpc.idmapd: Stale client: 9 rpc.idmapd: -> closed /var/lib/nfs/rpc_pipefs/nfs/clnt9/idmap rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server : (user) id "1000" -> name "steve@CACTUS" rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=group rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0 rpc.idmapd: nfs4_gid_to_name: final return value is 0 rpc.idmapd: Server : (group) id "100" -> name "users@CACTUS" rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server : (user) id "3000021" -> name "steve5@CACTUS" rpc.idmapd: nfs4_name_to_uid: calling nsswitch->name_to_uid rpc.idmapd: nss_getpwnam: name 'steve5@CACTUS' domain 'CACTUS': resulting localname 'steve5' rpc.idmapd: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 rpc.idmapd: nfs4_name_to_uid: final return value is 0 rpc.idmapd: Client 8: (user) name "steve5@CACTUS" -> id "3000021" Client and server agree on a user id 3000021, the server establishes group id as 100 but the client does not respond. Tested with KDC,nfsserver and client all on one box and with KDC and nfsserver on server box and client on a remote openSUSE 12.1 client. -- 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 <lynn@steve-ss.com> 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#c7 lynn wilson <lynn@steve-ss.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |FIXED --- Comment #7 from lynn wilson <lynn@steve-ss.com> 2012-02-01 08:44:07 UTC --- Found it. My fault. /etc/idmapd.conf must contain Domain=my.domain _not_ fqdn nor hostname nor any windows netbios domain you may be joined to. Will close the bug. 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 <lynn@steve-ss.com> 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.
participants (1)
-
bugzilla_noreply＠novell.com