svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd

[James Peach]

On Mar 29, 2007, at 10:35 AM, Jeremy Allison wrote:

> On Thu, Mar 29, 2007 at 10:23:57AM -0700, James Peach wrote:
>>
>> Why is having the ability to do this a good thing? If a client wants
>> to do unencrypted traffic it can always set up a new session.
>
> Yes, but the thing that convinced me was the ability
> to have the following :
>
> [share_secure]
>    encryption = mandatory
>    path = /xxxx
>
> [share_unsecure]
>    encryption = auto (or "no")
>    path = /yyy
>
> If we want the server to be able to make
> encryption mandatory and we don't allow
> it per share then we disallow that server
> from serving any unencrypted (currently
> Windows) clients.

You probably also want to allow shares to have different levels of  
encryption. For example,

[share_really_secure]
     encryption = mandatory
     minimum encryption = the_best_algorithm_we_implement

[homes]
     encryption = mandatory
     minimum encryption = the_faster_but_weaker_algorithm

> People probably want the ability to
> serve both encrypted and non encrypted
> shares from the saem server.
>
> Currently the point is moot as the
> implmentation only supported encryption
> context zero - ie. encrypt everything.
>
> But the goal is not to contrain the
> design.

There's 2 issues - the first is supporting the configuration above,  
the second is that the only space we have in the protocol is in trans2  
levels which require a tree connection.

If you wanted encryption to be a property of the VC, you could connect  
to [Samba$] and negotiate it there which would work around the second  
issue. If some shares require encryption and some don't you can just  
set up different VCs to handle it.

That said, we can live with having encryption as a property of the  
TID :)

--
James Peach | jpeach at samba.org