[linux-cifs-client] Re: 2 New encryption capability bits in UNIX extensions.

[Steve French]

Jeremy Allison wrote:

>On Thu, Mar 29, 2007 at 10:40:56AM -0700, George Colley wrote:
>  
>
>>So when do sealing we only do it at below the tree level? Shouldn't  
>>the whole VC be sealed? This seems a little strange to me. Why would  
>>you every want to seal one tree connection and not another on the  
>>same VC?
>>    
>>
>
>Currently if the encryption context returned by the server
>is zero, then all traffic is encrypted. If a non-zero
>context is returned then only traffic on the tid that
>initiated this context is encrypted. This gives us
>the ability to do both full session encryption as
>well as tid-only encryption.
>
>That's the design theory (from Steve :-).
>
>Jeremy.
>
>  
>
Two considerations ...
Perhaps it makes the spec a little more logical as the Unix/POSIX SetFSInfo
which emables sealing operates on a tid not a socket or smb session.  
Although
supporting this is not required (ie to implment for tid rather than tcp 
session),
as jra indicates it is possible for the server to implement it [only] 
over the
whole tcp connection (and not support it over a tid).  smb sealing is
a nice addition over what NFSv4 offers (or what you would get
configuring cifs over ipsec) for two reasons:
1) smb security is much easier to setup than ipsec
2) offering sealing over a subset of shares is very useful (many servers 
export different
shares for data files and program files).   For reading program files 
over a read-only
share why encrypt the data (signing may be sufficient)?  There is a 
large performance
pealty incurred with sealing.