| Message ID | 5283A3B7.8080405@netapp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Nov 13, 2013 at 11:07:19AM -0500, Anna Schumaker wrote:
> I'm thinking something like this:
Given that the whole sparse file support seems more experimental than
the security labels requiring the former for the latter seems a bit odd.
I have to admit that I don't really know how to deal with those changes,
on the one hand I'd love to expose it as soon as possible, on the other
hand the spec has so many higher level flaws related to their concepts
of sparse files that I'd feel really bad about locking even parts of it
in at the moment.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 13, 2013 at 08:15:27AM -0800, Christoph Hellwig wrote: > On Wed, Nov 13, 2013 at 11:07:19AM -0500, Anna Schumaker wrote: > > I'm thinking something like this: > > Given that the whole sparse file support seems more experimental than > the security labels requiring the former for the latter seems a bit odd. > > I have to admit that I don't really know how to deal with those changes, > on the one hand I'd love to expose it as soon as possible, on the other > hand the spec has so many higher level flaws related to their concepts > of sparse files that I'd feel really bad about locking even parts of it > in at the moment. This isn't a candidate for 3.13, and SEEK didn't look like the most problematic bit, so with a couple more months I'm hoping we'll be more confident about the protocol? Actually now that I look, I forget: even if security labels are built in, 4.2 is still off by default at runtime for now. We could add another interface to toggle individual features at run time but I think that's definitely too complicated. Maybe: - keep 4.2 off by default a runtime for now. - keep each feature under its individual config option: NFSD_V4_SECURITY_LABEL, NFSD_V4_SEEK, NFSD_V4_SEND_PONIES.... - when an individual feature matures, ditch its config option and build it unconditionally. We're always getting little build bugs due to untested build options so I'd rather not keep them around indefinitely. - once 4.2 has at least one feature that we think is mature enough, switch the runtime 4.2 default to on and depend on scary warnings on the remaining build options to keep people from exposing them in production. ? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 13, 2013 at 11:49:59AM -0500, J. Bruce Fields wrote: > This isn't a candidate for 3.13, and SEEK didn't look like the most > problematic bit, so with a couple more months I'm hoping we'll be more > confident about the protocol? Wish I knew. The ieft list seems to be at an awfully small pace, and the actual spec seems another layer separated from that. People who are more familar with the process might have to chime in. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 13, 2013 at 5:49 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > On Wed, Nov 13, 2013 at 08:15:27AM -0800, Christoph Hellwig wrote: >> On Wed, Nov 13, 2013 at 11:07:19AM -0500, Anna Schumaker wrote: >> > I'm thinking something like this: >> >> Given that the whole sparse file support seems more experimental than >> the security labels requiring the former for the latter seems a bit odd. >> >> I have to admit that I don't really know how to deal with those changes, >> on the one hand I'd love to expose it as soon as possible, on the other >> hand the spec has so many higher level flaws related to their concepts >> of sparse files that I'd feel really bad about locking even parts of it >> in at the moment. > > This isn't a candidate for 3.13, and SEEK didn't look like the most > problematic bit, so with a couple more months I'm hoping we'll be more > confident about the protocol? > > Actually now that I look, I forget: even if security labels are built > in, 4.2 is still off by default at runtime for now. > > We could add another interface to toggle individual features at run time > but I think that's definitely too complicated. > > Maybe: > > - keep 4.2 off by default a runtime for now. > - keep each feature under its individual config option: > NFSD_V4_SECURITY_LABEL, NFSD_V4_SEEK, NFSD_V4_SEND_PONIES.... > - when an individual feature matures, ditch its config option > and build it unconditionally. We're always getting little > build bugs due to untested build options so I'd rather not > keep them around indefinitely. > - once 4.2 has at least one feature that we think is mature > enough, switch the runtime 4.2 default to on and depend on > scary warnings on the remaining build options to keep people > from exposing them in production. NFSD_V4_SEND_PONIES is mandatory for 3.13!!!!! :) Josh -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/13/2013 11:49 AM, J. Bruce Fields wrote: > On Wed, Nov 13, 2013 at 08:15:27AM -0800, Christoph Hellwig wrote: >> On Wed, Nov 13, 2013 at 11:07:19AM -0500, Anna Schumaker wrote: >>> I'm thinking something like this: >> >> Given that the whole sparse file support seems more experimental than >> the security labels requiring the former for the latter seems a bit odd. >> >> I have to admit that I don't really know how to deal with those changes, >> on the one hand I'd love to expose it as soon as possible, on the other >> hand the spec has so many higher level flaws related to their concepts >> of sparse files that I'd feel really bad about locking even parts of it >> in at the moment. > > This isn't a candidate for 3.13, and SEEK didn't look like the most > problematic bit, so with a couple more months I'm hoping we'll be more > confident about the protocol? > > Actually now that I look, I forget: even if security labels are built > in, 4.2 is still off by default at runtime for now. > > We could add another interface to toggle individual features at run time > but I think that's definitely too complicated. > > Maybe: > > - keep 4.2 off by default a runtime for now. > - keep each feature under its individual config option: > NFSD_V4_SECURITY_LABEL, NFSD_V4_SEEK, NFSD_V4_SEND_PONIES.... > - when an individual feature matures, ditch its config option > and build it unconditionally. We're always getting little > build bugs due to untested build options so I'd rather not > keep them around indefinitely. > - once 4.2 has at least one feature that we think is mature > enough, switch the runtime 4.2 default to on and depend on > scary warnings on the remaining build options to keep people > from exposing them in production. > > ? That's doable too. And it keeps me from having to touch security label code that I don't know a whole lot about! Anna > > --b. > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 13, 2013 at 08:52:04AM -0800, Christoph Hellwig wrote: > On Wed, Nov 13, 2013 at 11:49:59AM -0500, J. Bruce Fields wrote: > > This isn't a candidate for 3.13, and SEEK didn't look like the most > > problematic bit, so with a couple more months I'm hoping we'll be more > > confident about the protocol? > > Wish I knew. The ieft list seems to be at an awfully small pace, It just varies depending on who's paying attention, I think. Tom's actually been taking changes pretty quickly once there's patches. > and the actual spec seems another layer separated from that. People > who are more familar with the process might have to chime in. Trond actually goes to those meetings on a regular basis, so he's probably the one to chime in. 4.0 and 4.1 were both kind of huge and monolithic, and I don't remember facing the problem of knowing when the specs were "done": the code wasn't going to be ready before the rfc's were published anyway. A lot of these 4.2 things look much simpler to implement, so now we've got the option of releasing things into the wild before there's an rfc. And if we screw up then we could end up sticking someone else with behavior they don't want. Better than specifying behavior that nobody wanted, which was more likely before--it's good to be reviewing specs and patches at the same time. But now I'm more vague on when to declare some part of the new spec stable. If there's no magic milestone then we just review and communicate as best we can, I guess.... --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/nfsd/Kconfig b/fs/nfsd/Kconfig index dc8f1ef..5d0ca71 100644 --- a/fs/nfsd/Kconfig +++ b/fs/nfsd/Kconfig @@ -81,9 +81,18 @@ config NFSD_V4 If unsure, say N. +config NFSD_V4_2 + bool "Server support for NFS v4.2" + depends on NFSD_V4 + help + This option enables support for minor version 2 of the NFSv4 protocol + in the kernel's NFS server. + + If unsure, say N. + config NFSD_V4_SECURITY_LABEL bool "Provide Security Label support for NFSv4 server" - depends on NFSD_V4 && SECURITY + depends on NFSD_V4_2 && SECURITY help Say Y here if you want enable fine-grained security label attribute