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

[Jeremy Allison]

On Fri, Mar 30, 2007 at 10:21:56AM +1000, tridge at samba.org wrote:
> 
> Can you explain what you are actually trying to achieve with this
> encryption work? Are you trying to protect file data? Or the SMB
> transport? Or something else?

The SMB transport for specific shares, and also the ability
to protect the entire transport itself (server option).

> Also, what are you trying to protect it from? From people reading on
> the wire what the user is doing? Or from someone doing a TCP hijack
> and changing the requests?

Both should be protected.

> If you are trying to protect file data, then it would make sense to
> encrypt the data being read and written - which means either a flag to
> readx/writex, or a new pair of read/write calls that encrypt the file
> data.

The goal is to be able to encrypt all operations specific to
a particular share other than the initial share tconX call.
ie. Have a concept of an "encrypted" share.

> If you are trying to protect the transport then a share specific
> "encryption" option makes no sense as you'd have to accept unencrypted
> open file requests to look at the TID and see what share they are
> making a request on. That means the filename is unprotected.

If a share is specified as encrypted then no unencrypted access
will be allowed - I don't see the problem here.

> I also can't really see the sense behind a setfsinfo request being
> used. Calling setfsinfo implies you are changing a property of a
> filesystem, but this encryption stuff has nothing to do with the
> filesystem - its all "on the wire" stuff. So why use setfsinfo?

The problem is we only have the trans2 space to work in. I'm
trying to fix this carefully into the space we have.

Jeremy.