headers
J. Bruce Fields | 4 Jan 2010 17:12

Re: [PATCH 0/7] nfs-utils - Dynamic Pseudo Root - Release 9

On Fri, Dec 18, 2009 at 05:51:01PM -0500, J. Bruce Fields wrote:
> On Tue, Dec 15, 2009 at 12:17:41PM -0500, J. Bruce Fields wrote:
> > Actually, it's tricky.  Suppose exports are:
> > 
> > 	P	*(sec=krb5)
> > 	P/Q	A(sec=sys)
> > 
> > When we get a request for (A,P) what do we do?
> > 
> > I believe our latest effort passes down an export something like:
> > 
> > 	P	A(sec=sys,v4root)
> > 
> > thus denying most access to P.
> > 
> > If we pass down
> > 
> > 	P	A(sec=krb5)
> > 
> > instead, then we (needlessly?) require krb5 access to mount P/Q.
> > 
> > Or we could try telling people not to do that.  That doesn't always
> > work.
> > 
> > Or we could find some way to make v4root vary by pseudoflavor, and pass
> > down something like:
> > 
> > 	P	A(sec=krb5,nov4root,sec=sys,v4root)
> > 
> > I don't see how to do that off hand.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Dickson | 4 Jan 2010 21:18
Picon
Favicon

Re: [PATCH] nfs4: Make the v4 callback service hidden


On 10/13/2009 04:07 PM, Steve Dickson wrote:
> Hey Trond,
> 
> As we talked about in another thread, v4 mount (and umounts) hang when
> rpcbind is not up and running because the callback thread ends up
> doing an svc_unregister() during both the mounts and unmounts.
> 
> So a simple and appropriate solution is to simply make the 
> nfs4_callback_program a 'vs_hidden' service, simple to the 
> ACL programs... Obviously its a simple fix but also appropriate
> becaue the callback program/service is truly a hidden service 
> since svc_register is never called...
> 
> Comments?
> 
> steved.
> 
> Author: Steve Dickson <steved <at> redhat.com>
> Date: Tue Oct 13 15:59:57 EDT 2009
> 
> To avoid hangs in the svc_unregister(), on version 4 mounts 
> (and unmounts), when rpcbind is not running, make the nfs4 callback 
> program an 'hidden' service by setting the 'vs_hidden' flag in the 
> nfs4_callback_version structure. 
> 
> Signed-off-by: Steve Dickson <steved <at> redhat.com>
> 
> diff -up linux-2.6.31.x86_64/fs/nfs/callback_xdr.c.orig linux-2.6.31.x86_64/fs/nfs/callback_xdr.c
> --- linux-2.6.31.x86_64/fs/nfs/callback_xdr.c.orig	2009-09-09 18:13:59.000000000 -0400
(Continue reading)

Permalink | Reply | 0 comments |
headers
David P. Quigley | 4 Jan 2010 21:31
Picon

Adding a new export option

I remember a while back hearing something about the export code being
rewritten. Was that the case or was I misremembering something else? I
want to add a new export option for Labeled NFS and I've been crawling
through the existing export code. If it is going to be changed I'll hold
off on this for now otherwise I'll keep working on it. Also looking at
the security flavor code it looks like those values get converted from a
string into a number. Is there a good example of an export option that
passes a complete string to the kernel?

Dave
Permalink | Reply | 3 comments |
headers
Steve Dickson | 4 Jan 2010 21:58
Picon
Favicon

Re: Adding a new export option


On 01/04/2010 03:31 PM, David P. Quigley wrote:
> I remember a while back hearing something about the export code being
> rewritten. Was that the case or was I misremembering something else? I
> want to add a new export option for Labeled NFS and I've been crawling
> through the existing export code. If it is going to be changed I'll hold
> off on this for now otherwise I'll keep working on it. Also looking at
> the security flavor code it looks like those values get converted from a
> string into a number. Is there a good example of an export option that
> passes a complete string to the kernel?
> 
I would wait a bit until we get the pseudo code ironed out... 
I believe we have the kernel code set and Bruce is about to post
some mountd code that will complete the picture... Hopefully this will
be all set by the EOW... 

steved.
Permalink | Reply | 2 comments |
headers
J. Bruce Fields | 4 Jan 2010 22:04

Re: Adding a new export option

On Mon, Jan 04, 2010 at 03:58:24PM -0500, Steve Dickson wrote:
> 
> 
> On 01/04/2010 03:31 PM, David P. Quigley wrote:
> > I remember a while back hearing something about the export code being
> > rewritten. Was that the case or was I misremembering something else? I
> > want to add a new export option for Labeled NFS and I've been crawling
> > through the existing export code. If it is going to be changed I'll hold
> > off on this for now otherwise I'll keep working on it. Also looking at
> > the security flavor code it looks like those values get converted from a
> > string into a number. Is there a good example of an export option that
> > passes a complete string to the kernel?

You could look at fsloc or uuid.

> I would wait a bit until we get the pseudo code ironed out... 
> I believe we have the kernel code set and Bruce is about to post
> some mountd code that will complete the picture... Hopefully this will
> be all set by the EOW... 

Yes.  There aren't any changes to the kernel export parsing code (e.g.,
svc_export_parse()), though, so it may be independent from your changes.

What were you thinking your new option would look like?

--b.
Permalink | Reply | 1 comment |
headers
David P. Quigley | 4 Jan 2010 22:12
Picon

Re: Adding a new export option

On Mon, 2010-01-04 at 16:04 -0500, J. Bruce Fields wrote:
> On Mon, Jan 04, 2010 at 03:58:24PM -0500, Steve Dickson wrote:
> > 
> > 
> > On 01/04/2010 03:31 PM, David P. Quigley wrote:
> > > I remember a while back hearing something about the export code being
> > > rewritten. Was that the case or was I misremembering something else? I
> > > want to add a new export option for Labeled NFS and I've been crawling
> > > through the existing export code. If it is going to be changed I'll hold
> > > off on this for now otherwise I'll keep working on it. Also looking at
> > > the security flavor code it looks like those values get converted from a
> > > string into a number. Is there a good example of an export option that
> > > passes a complete string to the kernel?
> 
> You could look at fsloc or uuid.
> 
> > I would wait a bit until we get the pseudo code ironed out... 
> > I believe we have the kernel code set and Bruce is about to post
> > some mountd code that will complete the picture... Hopefully this will
> > be all set by the EOW... 
> 
> Yes.  There aren't any changes to the kernel export parsing code (e.g.,
> svc_export_parse()), though, so it may be independent from your changes.
> 
> What were you thinking your new option would look like?
> 
> --b.

So basically in Labeled NFS we currently use the LSM framework to parse
and set labels on the files on the server. One of the operation modes is
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 6 Jan 2010 22:01
Picon
Favicon

[PATCH 05/18] mountd: don't require mountpoint in crossmnt case

Currently,

	mount --bind /path /path

where /path is a subdirectory of a crossmnt export, can cause client
hangs, since the kernel detects that as a mountpoint, but nfs-util's
is_mountpoint() function does not.

I don't see any sure-fire way to detect such mountpoints.  But that's
OK: it's harmless to allow this upcall to succeed even when the
directory is not a mountpoint, so let's just remove this check.

Signed-off-by: J. Bruce Fields <bfields <at> citi.umich.edu>
---
 utils/mountd/cache.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
index e340390..2468bc5 100644
--- a/utils/mountd/cache.c
+++ b/utils/mountd/cache.c
 <at>  <at>  -619,8 +619,7  <at>  <at>  static int is_subdirectory(char *subpath, char *path)
 	int l = strlen(path);

 	return strcmp(subpath, path) == 0
-		|| (strncmp(subpath, path, l) == 0 && path[l] == '/'
-		    && is_mountpoint(path));
+		|| (strncmp(subpath, path, l) == 0 && path[l] == '/');
 }
(Continue reading)

Permalink | Reply | 13 comments |
headers
J. Bruce Fields | 6 Jan 2010 22:01
Picon
Favicon

[PATCH 08/18] mountd: prefer non-V4ROOT exports.

If paths A and A/B are both exported, then we have a choice of exports
to return for A (or under A but still above A/B): we could return A
itself, or we could return a V4ROOT export leading to B.

For now, we will always prefer the non-V4ROOT export, whenever that is
an option.  This will allow clients to reach A/B as long as
adminstrators keep to the rule that the security on a parent permits the
union of the access permitted on any descendant.

In the future we may support more complicated arrangements.

(Note: this can't be avoided by simply not creating v4root exports with
the same domain and path, because different domains may have some
overlap.)

Signed-off-by: J. Bruce Fields <bfields <at> citi.umich.edu>
---
 utils/mountd/cache.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
index 2468bc5..d63e10a 100644
--- a/utils/mountd/cache.c
+++ b/utils/mountd/cache.c
 <at>  <at>  -657,6 +657,11  <at>  <at>  static nfs_export *lookup_export(char *dom, char *path, struct hostent *he)
 				found_type = i;
 				continue;
 			}
+
+			/* Always prefer non-V4ROOT mounts */
(Continue reading)

Permalink | Reply | 10 comments |
headers
J. Bruce Fields | 6 Jan 2010 22:01
Picon
Favicon

[PATCH 12/18] mountd: get_exportlist() cleanup

Comment clarification, minor style cleanup.

Signed-off-by: J. Bruce Fields <bfields <at> citi.umich.edu>
---
 utils/mountd/mountd.c |   11 ++++-------
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
index ecd7c35..a0a1f2d 100644
--- a/utils/mountd/mountd.c
+++ b/utils/mountd/mountd.c
 <at>  <at>  -612,20 +612,17  <at>  <at>  get_exportlist(void)
 				continue;
 			e = lookup_or_create_elist_entry(&elist, exp);

-			/* We need to check if we should remove
-			   previous ones. */
+			/* exports to "*" absorb any others */
 			if (i == MCL_ANONYMOUS && e->ex_groups) {
 				remove_all_clients(e);
 				continue;
 			}
-
-			if (i != MCL_FQDN && e->ex_groups) {
+			/* non-FQDN's absorb FQDN's they contain: */
+			if (i != MCL_FQDN && e->ex_groups)
 				prune_clients(exp, e);
-			}

-			if (exp->m_export.e_hostname [0] != '\0') {
(Continue reading)

Permalink | Reply | 6 comments |
headers
J. Bruce Fields | 6 Jan 2010 22:01
Picon
Favicon

[PATCH 09/18] exports: hide pseudo exports from clients

From: Steve Dickson <steved <at> redhat.com>

Don't show pseudo exports when clients ask to see what
is exported via the showmount mount command.

Signed-off-by: Steve Dickson <steved <at> redhat.com>
---
 utils/mountd/mountd.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
index 888fd8c..179ef17 100644
--- a/utils/mountd/mountd.c
+++ b/utils/mountd/mountd.c
 <at>  <at>  -540,6 +540,10  <at>  <at>  get_exportlist(void)

 	for (i = 0; i < MCL_MAXTYPES; i++) {
 		for (exp = exportlist[i].p_head; exp; exp = exp->m_next) {
+			 /* Don't show pseudo exports */
+			if (exp->m_export.e_flags & NFSEXP_V4ROOT)
+				continue;
+
 			for (e = elist; e != NULL; e = e->ex_next) {
 				if (!strcmp(exp->m_export.e_path, e->ex_dir))
 					break;
--

-- 
1.6.3.3
Permalink | Reply | 9 comments |

Gmane