On Tue, Aug 25, 2009 at 08:21:45PM -0400, Trond Myklebust wrote: > On Tue, 2009-08-25 at 18:37 -0500, Nicolas Williams wrote: > > Looking at code we have > > ... > > Sorry. I didn't mean to force you into detailed explanations of the > code. As a NetApp employee, I'm not sure I'm licensed to even run > OpenSolaris at this point, let alone look at the code. :-) Well, you don't need a license to look at it (though you might need permission from your employer, and they may not grant it), and I can't imagine that my mentioning a few function names could taint you in any way. Nor would I normally keep from mentioning actual OpenSolaris code on OpenSolaris discuss lists. If it helps generic protocol discussions I'm willing to refrain from further discussing code in any one thread once you ask that I do, but I'd much rather such discussions take place in the IETF NFSv4 WG mailing list instead then (where I would generally refrain from posting code). > > Which means that WRONGSEC -> SECINFO -> updates the entire mount's sec. > > OK. This is sort of what I expect we will do for Linux too. OK. > The protocol will even allow you to set the secinfo on a per-file basis. True. > That sounds insane to me, but... NFS clients typically allow you to mount individual files, not just directories. There's no "MOUNT" operation in the protocol. Mounts have traditionally been entirely a client-side concept. NFSv4 exposes server-side hierarchical filesystem mount structures to the clients, but there's still no MOUNT operation, and clients needn't even have a notion of "mount" (POSIX clients may have to, but others may not). Clients could even treat every FH as needing a "mount" (meaning df(1), mount(1M), nfsstat(1M), etcetera may list every single file and directory recently accessed as mounts). OpenSolaris could react to a WRONGSEC by instantiating a mount dynamically where there really shouldn't be one. It may even have to, so that sec= settings may be reported to users through existing interfaces (unless we don't care for that). The same might apply to Linux. This sort of complexity argues that SECINFO should be per-filesystem, but see below. > Anyhow, I think our Linux client should go with the 'remove security > flavours only on mountpoints' rule for now, and then we'll see in time > if any users can justify a more fine grained implementation. BTW, the same considerations apply to sub-shares with other option differences. For example (note: I've not tested this): server% mount /foo server% share -F nfs -o rw /foo server% mkdir /foo/bar server% mkdir /foo/ick server% share -F nfs -o ro /foo client% mount server:/foo /foo client% touch /foo/ick/a client% touch /foo/bar/a touch: cannot create /foo/bar/a: Read-only file system client% touch /foo/ick/b touch: cannot create /foo/bar/a: Read-only file system We ought either say that clients MUST cope with hierarchical shares within a single filesystem, or that hierarchical shares within a filesystem MUST NOT be allowed. I'm not sure that I'd be ready to say the latter, while on the other hand the complexity of the former is certainly a challenge. Nico -- -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
