On Mon, Feb 09, 2009 at 05:24:32PM -0500, Peter Staubach wrote: > Section 3.2 discusses handling if a security attribute is > changed while a client is holding a delegation to an object. > The text describes that the client should flush changes to the > server and relinquish the delegation. Why? Is access to an > open file on the client to be revoked? What happens on a > client which does not happen to be holding a delegation at the > time? > > This leads to a further question concerning client side caching > of these attributes. Is the client allowed to do caching? If > so, how would it go about doing cache validation? For DAC POSIX semantics are that open file references are not revoked when a file's owner/group/permissions (and/or ACL) change. MAC requires some sort of revocation. This can happen on the server-side whenever the client tries to access a file after it's been relabeled. The client might learn of this pretty late, but given that the user on the client would have been able to see the contents under the old label this timing seems to me to be acceptable. Recalling an open file delegation seems OK as a way to speed that up if the client can obtain a new delegation if it still has access to the file. The only other wrinkle is that multi-user clients need to let the server perform all access decisions for each user -- the client must not allow access using local MAC decisions based on cached file labels. > Section 4.1 includes an XXX reference probably to a draft > document. Is this the draft for RPCSEC_GSSAPI v3? No, it's not. As David explained, that I-D came later. > Section 4.1.1 discusses denying a request if a security > attribute can not be translated from one DOI to another. > What error should be returned? It seems to me that a new IMO NFS4ERR_ACCESS is good enough. > set of errors may potentially need to be introduced to > handle the new cases where servers need to inform clients > exactly what happened. [...] Perhaps, but I expect that production servers would return generic errors like NFS4ERR_ACCESS rather than newfangled ones like, say, NFS4ERR_NODOITRANS. There's no need to tell the client too much about why its request failed. It suffices that access was denied, and for that NFS4ERR_ACCESS is good enough. > Section 4.2.1 discusses a smart client and the need for a > common DOI. Could a client not implement its own translations > for the DOIs that it may choose to know about? It could. > Anyway, enough for the time being. I think that some more > detailed definitions and declarations need to be specified > in order to move along. Defnitely. Thanks for the comments! Nico -- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
