Hello, I've got a little problem with NFSv4 + Kerberos. I can do a mount with Kerberos with a valid ticket, but read-only. After the mount -vvv -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test/ I can see: #klist: Feb 6 07:22:47 Feb 6 17:22:43 nfs/nfsserver at my.domain #/var/heimdal/kdc.log: 2013-02-06T07:28:26 TGS-REQ clientnfs at my.domain from IPv4:192.168.0.23 for nfs/nfsserver at my.domain tcpdump: 14:59:36.140272 IP nfsclient.61011 > 192.168.0.21.kerberos-sec: 14:59:36.142301 IP 192.168.0.21.kerberos-sec > nfsclient.61011: I got "Permission denied" message when I try to mkdir or rm. As a root mount and as a user mount (sysctl vfs.usermounts=1). With -sec=sys it works read-write, but with -sec=krb5 read-only.. my /etc/exports: V4: /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask 255.255.255.0 /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask 255.255.255.0 -maproot=root -alldirs tried with V4: / .... as well. Added all the principals needed. Tried also with full qualified domain names. SSH works fine with Kerberos Do I need rpcsec_gss.patch? (according to http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup) or can I make it work somehow else? I used FreeBSD-9.1-RELEASE-i386-disc1 and FreeBSD-10.0-CURRENT-i386-20130202-r246254-release -- Greets Janusz
Janusz Bulik wrote:> Hello, > I've got a little problem with NFSv4 + Kerberos. I can do a mount with > Kerberos with a valid ticket, but read-only. > After the mount -vvv -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test/ > I can see: > > #klist: > Feb 6 07:22:47 Feb 6 17:22:43 nfs/nfsserver at my.domain > > #/var/heimdal/kdc.log: > 2013-02-06T07:28:26 TGS-REQ clientnfs at my.domain from IPv4:192.168.0.23 > for nfs/nfsserver at my.domain > > tcpdump: > 14:59:36.140272 IP nfsclient.61011 > 192.168.0.21.kerberos-sec: > 14:59:36.142301 IP 192.168.0.21.kerberos-sec > nfsclient.61011: > > I got "Permission denied" message when I try to mkdir or rm. As a root > mount and as a user mount (sysctl vfs.usermounts=1). > With -sec=sys it works read-write, but with -sec=krb5 read-only.. >Did you successfully read files under /mount_test? (I suspect no access would be closer to the truth than read-only, unless the non-root user with a valid TGT only has read access. Although I think it is technically possible to do so, typically "root" does not exist in a KDC as a user principal and, as such, "root" cannot do a kinit to get a TGT and that means "no access" to the kerberized mount point.)> my /etc/exports: > V4: /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask > 255.255.255.0 > /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask > 255.255.255.0 -maproot=root -alldirs > > tried with V4: / .... as well. > Added all the principals needed. > Tried also with full qualified domain names. > SSH works fine with Kerberos > > > Do I need rpcsec_gss.patch? (according to > http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup) > or can I make it work somehow else? > > I used FreeBSD-9.1-RELEASE-i386-disc1 > and > FreeBSD-10.0-CURRENT-i386-20130202-r246254-release >Well, without the patch, the only kind of NFSv4 kerberized mount that will work is (NFSv3 is a different story): # sysctl vfs.usermount=1 - logged in as non-root user that has kinit'd and, therefore, has a valid TGT % mount -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test - then this user (or any other non-root user with a valid TGT) should be able to access /mount_test with whatever permissions the server has on the directories. (ie. If these users are supposed to create files/directories under /export_test, they will need write access to /export_test.) Note that "root" does not normally have any access to a kerberized mount point, since the KDC doesn't normally have a user principal for "root", as above. This mount will only work as long as the non-root user that did the mount holds a valid TGT. - To do an NFSv4 kerberized mount as root (which will keep working until unmount), you need to patch the system so that it can use a host based credential in the default keytab file as an initiator credential. If you use current/10.0 sources, I have a better patch to do this. It is at: http://people.freebsd.org/~rmacklem/rpcsec_gss-hostbased-initiator.patch After applying the patch, you need to build both the kernel and the gssd daemon from sources. You do not need to set the sysctl to the correct encryption type for the keytab entry to get it to work. After putting an entry in the client's /etc/keytab, rebooting the patched kernel with the rebuilt gssd daemon running on it, the mount looks like: # mount -t nfs -o nfsv4,sec=krb5,gssname=nfs nfsserver:/ /mount_test (Assuming that the keytab entry is for nfs/client-host.domain at YOUR_REALM.) This mount will still not give "root" access to the file system, for the same reasons as above, but can be done by "root" and doesn't need any valid TGT to keep working. At this time, there is no way to give "root" access to a kerberized mount unless you put a user principal for "root" (root at YOUR_REALM) in you KDC and then do a kinit when logged in as root. (This is not recommended from a security point of view.) If you can't get things to work: - try and use des-cbc-crc encryption for the keytab entries (you can try other ones after you have it working, so long as they result in an 8byte session key) - make sure the gssd is working on both client and server (it has to be running before the nfsd is started on the server) - check /var/log/messages for any messages from the gssd - check the log file on your KDC for hints of problems - capture packets of the mount and look at them in wireshark (use something like a "host" filter, so you get more than the NFS packets) Good luck with it, rick> -- > Greets > Janusz > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe at freebsd.org"
On 08/02/2013 01:05, Janusz Bulik wrote:> Hello, > I've got a little problem with NFSv4 + Kerberos. I can do a mount with > Kerberos with a valid ticket, but read-only. > After the mount -vvv -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test/> I got "Permission denied" message when I try to mkdir or rm. As a root > mount and as a user mount (sysctl vfs.usermounts=1). > With -sec=sys it works read-write, but with -sec=krb5 read-only..Am I right in supposing that you have never had this working? What you describe sounds symptomatic of nfsuserd not running - see nfsv4(4). sec=sys doesn't need nfsuserd to "work" but sec=krb5 does. If you mount with sec=krb5 and "ls -l /mount_test/" do you see in the listing the user and group names you expect, or just a bunch of numbers? The read-only access is probably what the filesystem permissions allow to "other" because, without nfsuserd, it can't map your kerberos principal to a uid. Of course, I could be wrong... -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130208/7912dd4b/attachment.sig>
Janusz Bulik wrote:> Hello, > I've got a little problem with NFSv4 + Kerberos. I can do a mount with > Kerberos with a valid ticket, but read-only. > After the mount -vvv -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test/ > I can see: > > #klist: > Feb 6 07:22:47 Feb 6 17:22:43 nfs/nfsserver at my.domain > > #/var/heimdal/kdc.log: > 2013-02-06T07:28:26 TGS-REQ clientnfs at my.domain from IPv4:192.168.0.23 > for nfs/nfsserver at my.domain > > tcpdump: > 14:59:36.140272 IP nfsclient.61011 > 192.168.0.21.kerberos-sec: > 14:59:36.142301 IP 192.168.0.21.kerberos-sec > nfsclient.61011: > > I got "Permission denied" message when I try to mkdir or rm. As a root > mount and as a user mount (sysctl vfs.usermounts=1). > With -sec=sys it works read-write, but with -sec=krb5 read-only.. > > my /etc/exports: > V4: /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask > 255.255.255.0 > /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask > 255.255.255.0 -maproot=root -alldirs > > tried with V4: / .... as well. > Added all the principals needed. > Tried also with full qualified domain names. > SSH works fine with Kerberos > > > Do I need rpcsec_gss.patch? (according to > http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup) > or can I make it work somehow else? > > I used FreeBSD-9.1-RELEASE-i386-disc1 > and > FreeBSD-10.0-CURRENT-i386-20130202-r246254-release >Thanks to Elias's hard work, a bug/fix for a Kerberos function has been identified that can make the gssd fail to map a principal to a uid. (I haven't run into this bug, so I don't know what systems are affected.) See this thread: http://docs.FreeBSD.org/cgi/mid.cgi?CADtN0WKVzbKxhaLQw8y2KLhhRJC9n4ht9wyPmGQ+pHqSjQkVNw I'd suggest you apply the patch (increasing the size of buf to 1024) and then try testing with libraries built with this patch applied. Good luck with it, rick> -- > Greets > Janusz > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe at freebsd.org"
Janusz Bulik wrote:> Hello, > I've got a little problem with NFSv4 + Kerberos. I can do a mount with > Kerberos with a valid ticket, but read-only. > After the mount -vvv -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test/ > I can see: > > #klist: > Feb 6 07:22:47 Feb 6 17:22:43 nfs/nfsserver at my.domain > > #/var/heimdal/kdc.log: > 2013-02-06T07:28:26 TGS-REQ clientnfs at my.domain from IPv4:192.168.0.23 > for nfs/nfsserver at my.domain > > tcpdump: > 14:59:36.140272 IP nfsclient.61011 > 192.168.0.21.kerberos-sec: > 14:59:36.142301 IP 192.168.0.21.kerberos-sec > nfsclient.61011: > > I got "Permission denied" message when I try to mkdir or rm. As a root > mount and as a user mount (sysctl vfs.usermounts=1). > With -sec=sys it works read-write, but with -sec=krb5 read-only.. > > my /etc/exports: > V4: /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask > 255.255.255.0 > /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask > 255.255.255.0 -maproot=root -alldirs > > tried with V4: / .... as well. > Added all the principals needed. > Tried also with full qualified domain names. > SSH works fine with Kerberos > > > Do I need rpcsec_gss.patch? (according to > http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup) > or can I make it work somehow else? > > I used FreeBSD-9.1-RELEASE-i386-disc1 > and > FreeBSD-10.0-CURRENT-i386-20130202-r246254-release >That sounds just like the problem isolated/fixed by Elias. I can't remember if I already sent you email on this, but you should try: Increasing the size of buf[128] to buf[1024] in both: - usr.sbin/gssd/gssd.c - kerberos5/lib/libgssapi_krb5/pname_to_uid.c and then rebuild/reinstall world. rick> -- > Greets > Janusz > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe at freebsd.org"