Date: Tue, 1 Dec 2015 08:41:46 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: hackers@freebsd.org Subject: Re: NFSv4 details and documentations Message-ID: <1745794347.113212991.1448977306722.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20151201074425.GD31314@zxy.spb.ru> References: <9BC3EFA2-945F-4C86-89F6-778873B58469@cs.huji.ac.il> <20151116141433.GA31314@zxy.spb.ru> <1489367909.88538127.1447688459383.JavaMail.zimbra@uoguelph.ca> <20151116155710.GB31314@zxy.spb.ru> <1312967974.89238067.1447714816355.JavaMail.zimbra@uoguelph.ca> <20151130165940.GB31314@zxy.spb.ru> <183609075.112643195.1448924896262.JavaMail.zimbra@uoguelph.ca> <20151201074425.GD31314@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Slawa Olhovchenkov wrote: > On Mon, Nov 30, 2015 at 06:08:16PM -0500, Rick Macklem wrote: > > > Slawa Olhovchenkov wrote: > > > On Mon, Nov 16, 2015 at 06:00:16PM -0500, Rick Macklem wrote: > > > > > > > > But this is wrong: not only exported, access control too. > > > > > May be for NFS guru this is trivia, but for ordinary users this is > > > > > confused. > > > > > > > > > > > > What current status Kerberos support in NFS client/server? I > > > > > > > found > > > > > > > many posts and wiki pages about lack some functionality, but also > > > > > > > see > > > > > > > many works from you. > > > > > > > > > > > > > The main limitation (which comes from the fact that the RPCSEC_GSS > > > > > > implementation > > > > > > is version 1) is that it expects to use DES, which requires "weak > > > > > > authentication" > > > > > > to be enabled. Although parts about adding patches for initiator > > > > > > credentials no longer > > > > > > applies, this is still fairly useful. > > > > > > > > > > Hmm, I am have setup Kerberized NFS w/o "weak authentication" to be > > > > > enabled, with mounted as > > > > > 'nfsv4,intr,soft,sec=krb5i,allgssname,gssname=root'. What is requred > > > > > DES in RPCSEC_GSS? (for me as user, how I can see what broken? some > > > > > commands don't working or something else?) > > > > > > > > > Well, if the mount is working, you aren't broken. I do recommend > > > > against > > > > using "soft" or "intr" on NFSv4 mounts, because the locking stuff > > > > (which includes file opens) breaks if an RPC gets interrupted. > > > > That is on one of the man pages, maybe "man nfsv4". > > > > > > > > Usually you can't create the keytab entries unless you enable weak > > > > authentication, > > > > but if you've gotten it working, be happy;-) > > > > (DES is used for krb5p and none of the Kerberized NFS stuff works for > > > > excryption types with larger keys than 8 bytes, from what I know. I > > > > always used des-cbc-crc, because that is what all clients/servers are > > > > supposed to support. Once you move away from that, you are > > > > experimenting > > > > and it works or not.) > > > > > > mount is working, but all access (from any accounts) go from mounting > > > credentials (if I mount allgssname,gssname=host -- as root and mapped > > > to nobody, if I mount as user -- all access as user, root also as > > > user). What I am missing or missunderstund? > > > > > Yes, that sounds correct. The mapping of "root" is somewhat more unusual. > > It depends on what you called the host-based principal in your > > /etc/krb5.keytab. > > If you use "root@<client-host>.<domain>", then system operations are done > > as > > "root", assuming you have "root" in your KDC (most don't). Otherwise, > > "root" > > ends up as "nobody". > > > > The most common variant of the mount (which requires a host-based > > credential in > > /etc/krb5.keytab on the client) is done with gssname=host (but not > > "allgssname"). > > Yes, my mount use "allgssname", I am think "gssname=host" require > "allgssname" too. > > > (Note that "host" here implies that the principal for the host-based > > credential is > > "host@<client-host>.<domain>". --> What is after the "=" above is what is > > before the > > "@" in the host based principal name.) > > Then system operations are done as nobody, but users are done as that user > > (they need > > This is strange. I am mount (by automount) as: > > /NFS -nfsv4,intr,soft,sec=krb5i,gssname=host storage01:/ > I'd recommend that you never use "intr" or "soft" on NFSv4 mounts. (It's somewhere in a man page and basically if you use these and an RPC that does locking times out, you break the locking horribly.) Also, I never use automount. I'd suggest you try the mount command typed manually and then once you have it working, then try the automount and see if it works. > in rc.conf: > gssd_enable="YES" > gssd_flags="-h" > On the client, this looks correct. > In this case, I am can't login to user with $HOME on this NFS -- > root (sshd run as root and PAM accounting run as root -- check > .k5login and etc) totaly don't have access (10016). > This means that the client fell back to AUTH_SYS and the server doesn't accept that. Getting a home directory to work is harder than it should be and I don't even know how to make it work, because I haven't done it. The login must do a "kinit" so the user has access to the volume and I don't know how to set FreeBSD up to do the kinit as a part of the login. It also must be done early enough in the login, so that it happens before any access to the home dir is attempted. (To be honest, unless there is a way to do this in FreeBSD, you can forget about Kerberized NFS mounts for home dirs.) I would start by testing a mount that isn't a home directory, so you can log into the machine (home dir not Kerberized NFS mounted) and then the user can "kinit" and them "cd /kerberized/mount" and see if it works. --> Once that works, I don't know how to do the rest. (I'm an NFS guy, not a Kerberos one.;-) Also, I don't know what effect having sshd etc running as root will be, since they will then be seen as running by "nobody" on the server. > I am avoid this by "kinit -k host/`hostname`" in crontab and startup > script, but may be gssd is best for this functionality? > Shouldn't matter. "gssd -h" does exactly the same stuff as "kinit -k". (I wrote the code essentially cloning what "kinit -k" did.) > > to "kinit"). The "allgssname" is an odd case for some server no one logs > > into, which > > says "do everything as the host based credential. > > I am confused by "allgssname", I am don't think that is like -mapall= > in exports, I am think this is only for mount and for case absent user > principal. > It simply says "do all RPCs with the host based credential" which means the uid etc is completely ignored. This works for cases where users can't "kinit", but everything is run as "nobody" and not the user, so it isn't very useful. (Other Kerberized NFS setups like Linux don't even have this as far as I remember.) > > --> If you need "root" access, you must put a "root" principal name in your > > KDC and > > then create the host-based credential for /etc/krb5.keytab using the > > principal > > name "root@<client-host>.<domain>". I don't think this is true for FreeBSD. It was what I did in the code I wrote long ago for OpenBSD and this wasn't ported to FreeBSD. Sorry for the confusion. I don't use Kerberos and avoid it like the plague. Good luck with it, rick > > > > Yes, it is confusing, but that's Kerberos for you;-) rick > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1745794347.113212991.1448977306722.JavaMail.zimbra>