* [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL @ 2014-04-26 16:35 Thomas Haynes 2014-04-26 16:37 ` Thomas Haynes 2014-05-01 14:07 ` [nfsv4] " Jeff Layton 0 siblings, 2 replies; 5+ messages in thread From: Thomas Haynes @ 2014-04-26 16:35 UTC (permalink / raw) To: nfsv4 list (nfsv4@ietf.org), Mailing List Linux NFS [-- Attachment #1.1: Type: text/plain, Size: 1903 bytes --] In my issues file, I have: 4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to be? Is seLinux going to support it? The Labeled NFS prototype in use does not currently support change_sec_label. In the past, we argued about how big it needed to be - we need to close down on this. If we look at the current text in the NFSv4.2 draft, we see: The second change is to provide methods for the client to determine if the security label has changed. A client which needs to know if a label is going to change SHOULD request a delegation on that file. In order to change the security label, the server will have to recall all delegations. This will inform the client of the change. If a client wants to detect if the label has changed, it MAY use VERIFY and NVERIFY on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL has been modified. So the first question is do we need two methods for detecting that the label has changed? Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt covers how the client could use delegations to detect a label change. To quote Trond out of context: but that is the only option I can see for implementing a cache consistency model for labels. Without it, the choices are: 1) always fetch the label as part of every COMPOUND. 2) assume the label never changes on the server. The main use cases that have been presented for Labeled NFS on Linux would tend to push me towards door number 2, Monty please... So a client could assume that the label never changes the majority of the time. Once it decides it does need to start checking for a change in the label, it can get a delegation. If we do need the attribute, what size does it need to be? There has been mention of it being a hash or a timestamp. [-- Attachment #1.2: Type: text/html, Size: 2881 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Resolving the fate of FATTR4_CHANGE_SEC_LABEL 2014-04-26 16:35 [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL Thomas Haynes @ 2014-04-26 16:37 ` Thomas Haynes 2014-05-01 14:07 ` [nfsv4] " Jeff Layton 1 sibling, 0 replies; 5+ messages in thread From: Thomas Haynes @ 2014-04-26 16:37 UTC (permalink / raw) To: nfsv4 list (nfsv4@ietf.org), Mailing List Linux NFS Cc: dpquigl@davequigley.com Quigley In my issues file, I have: 4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to be? Is seLinux going to support it? The Labeled NFS prototype in use does not currently support change_sec_label. In the past, we argued about how big it needed to be - we need to close down on this. If we look at the current text in the NFSv4.2 draft, we see: The second change is to provide methods for the client to determine if the security label has changed. A client which needs to know if a label is going to change SHOULD request a delegation on that file. In order to change the security label, the server will have to recall all delegations. This will inform the client of the change. If a client wants to detect if the label has changed, it MAY use VERIFY and NVERIFY on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL has been modified. So the first question is do we need two methods for detecting that the label has changed? Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt covers how the client could use delegations to detect a label change. To quote Trond out of context: > but that is the only option I can see for implementing a cache > consistency model for labels. Without it, the choices are: > > 1) always fetch the label as part of every COMPOUND. > 2) assume the label never changes on the server. > > The main use cases that have been presented for Labeled NFS on Linux > would tend to push me towards door number 2, Monty please... So a client could assume that the label never changes the majority of the time. Once it decides it does need to start checking for a change in the label, it can get a delegation. If we do need the attribute, what size does it need to be? There has been mention of it being a hash or a timestamp. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL 2014-04-26 16:35 [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL Thomas Haynes 2014-04-26 16:37 ` Thomas Haynes @ 2014-05-01 14:07 ` Jeff Layton 2014-05-01 14:16 ` Tom Haynes 1 sibling, 1 reply; 5+ messages in thread From: Jeff Layton @ 2014-05-01 14:07 UTC (permalink / raw) To: Thomas Haynes; +Cc: nfsv4 list (nfsv4@ietf.org), Mailing List Linux NFS On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes <thomas.haynes@primarydata.com> wrote: > In my issues file, I have: > > 4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to > be? Is seLinux going to support it? > > The Labeled NFS prototype in use does not currently support > change_sec_label. > > In the past, we argued about how big it needed to be - we need > to close down on this. > > If we look at the current text in the NFSv4.2 draft, we see: > > The second change is to provide methods for the client to > determine if the security label has changed. A client which > needs to know if a label is going to change SHOULD request a > delegation on that file. In order to change the security > label, the server will have to recall all delegations. This > will inform the client of the change. If a client wants to > detect if the label has changed, it MAY use VERIFY and NVERIFY > on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL > has been modified. > > So the first question is do we need two methods for detecting that the label > has changed? > > Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt > covers > how the client could use delegations to detect a label change. > > To quote Trond out of context: > > but that is the only option I can see for implementing a cache > consistency model for labels. Without it, the choices are: > > 1) always fetch the label as part of every COMPOUND. > 2) assume the label never changes on the server. > > The main use cases that have been presented for Labeled NFS on Linux > would tend to push me towards door number 2, Monty please... > In principle, the label should only rarely change, but they do change for various reasons (admin goofs and forgets to set the label in the first place and then needs to fix it, SELinux policy changes mandate that a label changes from some type to another, etc). I think assuming that the label never changes would be very problematic. If the label does change, you'd basically need to remount on the client. That said, I don't see any real need to treat the label differently from any other attribute. If you're trying to use these for client-side enforcement, then you just need to be aware that you can race with label changes on the server. > > So a client could assume that the label never changes the majority > of the time. Once it decides it does need to start checking for a change > in the label, it can get a delegation. > > If we do need the attribute, what size does it need to be? > > There has been mention of it being a hash or a timestamp. > I guess part of the problem is that we're trying to do client-side enforcement with these labels, and that's always going to be difficult. The server should really be what's doing the enforcement. Once we have that, we can just treat the security label like any other attribute and not worry about cache coherency. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL 2014-05-01 14:07 ` [nfsv4] " Jeff Layton @ 2014-05-01 14:16 ` Tom Haynes 2014-05-02 15:31 ` Tom Haynes 0 siblings, 1 reply; 5+ messages in thread From: Tom Haynes @ 2014-05-01 14:16 UTC (permalink / raw) To: Jeff Layton; +Cc: nfsv4 list (nfsv4@ietf.org), Mailing List Linux NFS > On May 1, 2014, at 7:07 AM, Jeff Layton <jlayton@poochiereds.net> wrote: > > On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes > <thomas.haynes@primarydata.com> wrote: >> In my issues file, I have: >> >> 4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to >> be? Is seLinux going to support it? >> >> The Labeled NFS prototype in use does not currently support >> change_sec_label. >> >> In the past, we argued about how big it needed to be - we need >> to close down on this. >> >> If we look at the current text in the NFSv4.2 draft, we see: >> >> The second change is to provide methods for the client to >> determine if the security label has changed. A client which >> needs to know if a label is going to change SHOULD request a >> delegation on that file. In order to change the security >> label, the server will have to recall all delegations. This >> will inform the client of the change. If a client wants to >> detect if the label has changed, it MAY use VERIFY and NVERIFY >> on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL >> has been modified. >> >> So the first question is do we need two methods for detecting that the label >> has changed? >> >> Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt >> covers >> how the client could use delegations to detect a label change. >> >> To quote Trond out of context: >> >> but that is the only option I can see for implementing a cache >> consistency model for labels. Without it, the choices are: >> >> 1) always fetch the label as part of every COMPOUND. >> 2) assume the label never changes on the server. >> >> The main use cases that have been presented for Labeled NFS on Linux >> would tend to push me towards door number 2, Monty please... > > In principle, the label should only rarely change, but they do change > for various reasons (admin goofs and forgets to set the label in the > first place and then needs to fix it, SELinux policy changes mandate > that a label changes from some type to another, etc). I think assuming > that the label never changes would be very problematic. If the label > does change, you'd basically need to remount on the client. > > That said, I don't see any real need to treat the label differently > from any other attribute. If you're trying to use these for > client-side enforcement, then you just need to be aware that you can > race with label changes on the server. > >> >> So a client could assume that the label never changes the majority >> of the time. Once it decides it does need to start checking for a change >> in the label, it can get a delegation. >> >> If we do need the attribute, what size does it need to be? >> >> There has been mention of it being a hash or a timestamp. > > I guess part of the problem is that we're trying to do client-side > enforcement with these labels, and that's always going to be > difficult. The server should really be what's doing the enforcement. > Once we have that, we can just treat the security label like any other > attribute and not worry about cache coherency. So are you advocating one of: 1) No detection of change 2) Client gets a delegation 3) Use the new attribute FWIW, I like #2. :-) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL 2014-05-01 14:16 ` Tom Haynes @ 2014-05-02 15:31 ` Tom Haynes 0 siblings, 0 replies; 5+ messages in thread From: Tom Haynes @ 2014-05-02 15:31 UTC (permalink / raw) To: Jeff Layton; +Cc: nfsv4 list (nfsv4@ietf.org), Mailing List Linux NFS On May 1, 2014, at 10:16 AM, Tom Haynes <thomas.haynes@primarydata.com> wrote: > > >> On May 1, 2014, at 7:07 AM, Jeff Layton <jlayton@poochiereds.net> wrote: >> >> On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes >> <thomas.haynes@primarydata.com> wrote: >>> In my issues file, I have: >>> >>> 4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to >>> be? Is seLinux going to support it? >>> >>> The Labeled NFS prototype in use does not currently support >>> change_sec_label. >>> >>> In the past, we argued about how big it needed to be - we need >>> to close down on this. >>> >>> If we look at the current text in the NFSv4.2 draft, we see: >>> >>> The second change is to provide methods for the client to >>> determine if the security label has changed. A client which >>> needs to know if a label is going to change SHOULD request a >>> delegation on that file. In order to change the security >>> label, the server will have to recall all delegations. This >>> will inform the client of the change. If a client wants to >>> detect if the label has changed, it MAY use VERIFY and NVERIFY >>> on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL >>> has been modified. >>> >>> So the first question is do we need two methods for detecting that the label >>> has changed? >>> >>> Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt >>> covers >>> how the client could use delegations to detect a label change. >>> >>> To quote Trond out of context: >>> >>> but that is the only option I can see for implementing a cache >>> consistency model for labels. Without it, the choices are: >>> >>> 1) always fetch the label as part of every COMPOUND. >>> 2) assume the label never changes on the server. >>> >>> The main use cases that have been presented for Labeled NFS on Linux >>> would tend to push me towards door number 2, Monty please... >> >> In principle, the label should only rarely change, but they do change >> for various reasons (admin goofs and forgets to set the label in the >> first place and then needs to fix it, SELinux policy changes mandate >> that a label changes from some type to another, etc). I think assuming >> that the label never changes would be very problematic. If the label >> does change, you'd basically need to remount on the client. >> >> That said, I don't see any real need to treat the label differently >> from any other attribute. If you're trying to use these for >> client-side enforcement, then you just need to be aware that you can >> race with label changes on the server. >> >>> >>> So a client could assume that the label never changes the majority >>> of the time. Once it decides it does need to start checking for a change >>> in the label, it can get a delegation. >>> >>> If we do need the attribute, what size does it need to be? >>> >>> There has been mention of it being a hash or a timestamp. >> >> I guess part of the problem is that we're trying to do client-side >> enforcement with these labels, and that's always going to be >> difficult. The server should really be what's doing the enforcement. >> Once we have that, we can just treat the security label like any other >> attribute and not worry about cache coherency. > > So are you advocating one of: > > 1) No detection of change > 2) Client gets a delegation > 3) Use the new attribute > > FWIW, I like #2. :-) > > And we’ve gone with #2. We can revisit the new attribute in NFSv4.3 if we find we actually have a use for it. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-05-02 15:31 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-26 16:35 [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL Thomas Haynes 2014-04-26 16:37 ` Thomas Haynes 2014-05-01 14:07 ` [nfsv4] " Jeff Layton 2014-05-01 14:16 ` Tom Haynes 2014-05-02 15:31 ` Tom Haynes
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.