svn commit: samba r21991 - in branches/SAMBA_3_0/source:
include lib libsmb smbd
James Peach
jpeach at samba.org
Thu Mar 29 18:32:59 GMT 2007
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
More information about the samba-technical
mailing list