From: "Brian J. Murrell" <brian-SquOHqY54CVWr29BmMi2cA@public.gmane.org>
To: linux-nfs@vger.kernel.org
Subject: Re: gssapi and nfs4
Date: Wed, 05 Nov 2008 00:25:29 -0500 [thread overview]
Message-ID: <1225862729.13506.8.camel@pc.interlinx.bc.ca> (raw)
In-Reply-To: <20081104224817.GB16121@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 3887 bytes --]
On Tue, 2008-11-04 at 17:48 -0500, J. Bruce Fields wrote:
>
> You can still vary ro/rw based on machine or security flavor; e.g.
>
> /home foo(sec=krb5,ro)
> /home bar(sec=krb5,rw)
Excellent.
> or
>
> /home foo(ro,sec=krb5,rw)
>
> (readable by all users, writeable only by krb5 users).
Ahhh. Very interesting.
> This should all
> be documented by "man exports".
Yes, it appears to be. My use of gss/krb5(...) was from some "howto"s
that I found on the web. Seems they are tad dated.
> > I did notice the bit of text about the single pseudo filesystem. Given
> > that on my server, I exported a number of filesystems, including / to
> > privileged (I'm in a very small and trusted environment) clients, it
> > seemed natural to just set / to fsid 0. I also exported the few other
> > exports I wanted some nfs4 clients to mount as such:
> >
> > / gss/krb5i(rw,insecure,sync,wdelay,no_subtree_check,no_root_squash,fsid=0,crossmnt,anonuid=65534,anongid=65534)
> > /home gss/krb5i(rw,no_root_squash,sync,subtree_check,anonuid=65534,anongid=65534)
> > /mnt/data gss/krb5i(rw,sync,subtree_check,crossmnt,anonuid=65534,anongid=65534)
> > /mnt/data/photos gss/krb5i(rw,sync,subtree_check,anonuid=65534,anongid=65534)
> >
> > where those are all on different filesystems on the server. I'm
> > starting to feel like this is not how it's supposed to be done.
>
> That'll work--but do you really want "/" to be accessible (writeable,
> even!) over nfs?
Writable, probably not, not for most anyway. A very select few,
perhaps. But still, probably not even readable for most. So how to
solve? Not export / as the pseudo filesystem? Or use an ip/netmask
that makes it impossible to match, or as the one bit of text I read
offered, bind mount everything you want to export into your "export"
tree? This last option seems a bit cumbersome given that everything I
want to export is already mounted and available under /.
Is there any way to limit/match on krb5 principals rather than IPs?
So in the situation of exporting / as fsid 0 (but this would be equally
applicable to an "/export" configuration that bind mounted a filesystem
under /export and then bind mounted a filesystem under that) given that
I have other filesystems mounted under / that I want to export as well,
(i.e. /usr) it's seemed necessary to use the "crossmnt" option on the
fsid 0 export. Is this correct?
So if I do export / as fsid=0,ro my guess is that I have to also export
any subdirs that I want to make "rw" separately, and mount them
separately on the client. i.e.
/ 10.75.22.0/24(sec=krb5,ro,insecure,sync,wdelay,no_subtree_check,root_squash,fsid=0,crossmnt)
/home 10.75.22.0/24(sec=krb5,rw,no_root_squash,sync,no_subtree_check)
/d 10.75.22.0/24(sec=krb5,rw,no_root_squash,sync,no_subtree_check,crossmnt)
/d/sub pc(sec=krb5,rw,no_root_squash,sync,no_subtree_check)
and on the clinet:
pc # mount -t nfs4 -o sec=krb5 server:/ /mnt/server
pc # mount -t nfs4 -o sec=krb5 server:/home /mnt/server/home
pc # mount -t nfs4 -o sec=krb5 server:/d /d
pc # mount -t nfs4 -o sec=krb5 server:/d/sub /d/sub
To have /home rw under /mnt/server. It would be there but ro without
the second mount, yes?
It also appears that for the above case of /d and /d/sub I need the
crossmnt option on /d or I don't see anything in /d/sub even though I've
exported and mounted it individually. Does this seem like the expected
behaviour or a bug? It's important to be able to do because I might
want to be able to export /d to certain hosts without giving them access
to mountpoints within /d as I have done above with /d/sub and pc. If I
use crossmnt which my experience is showing I need, then /d/sub is
exposed to all of 10.75.22.0/24 which is not what I want.
Thanx,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2008-11-05 5:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-04 15:43 gssapi and nfs4 Brian J. Murrell
2008-11-04 18:00 ` William A. (Andy) Adamson
[not found] ` <89c397150811041000l93b9831w1e8dce2175c6d51f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-04 18:53 ` Brian J. Murrell
2008-11-04 22:48 ` J. Bruce Fields
2008-11-05 5:25 ` Brian J. Murrell [this message]
[not found] ` <1225862729.13506.8.camel-lA68w17JHpfIgqYUaR6mlLDks+cytr/Z@public.gmane.org>
2008-11-05 19:02 ` J. Bruce Fields
2008-11-05 19:18 ` Brian J. Murrell
[not found] ` <1225912734.3785.40.camel-lA68w17JHpfIgqYUaR6mlLDks+cytr/Z@public.gmane.org>
2008-11-05 19:40 ` William A. (Andy) Adamson
[not found] ` <89c397150811051140p2f6e1cb1x1960570d19ac5d6d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-05 19:51 ` Brian J. Murrell
2008-11-06 21:50 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1225862729.13506.8.camel@pc.interlinx.bc.ca \
--to=brian-squohqy54cvwr29bmmi2ca@public.gmane.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox