New Proxy Unix CAP

Sam Liddicott sam at liddicott.com
Mon Apr 21 08:44:41 GMT 2008


* James Peach wrote, On 20/04/08 18:33:
> Is this intended to be an open protocol extension that other SMB
> vendors would implement? 
yes
> If so, could you please add documentation to
> <http://wiki.samba.org/index.php/UNIX_Extensions>, or a page that is
> linked from there.
I will; thanks for the tip
>
>> The conclusion was that ntioctl was the cleanest way to provide that
>> channel (allowing windows server based implementations through
>> pluggable ioctl handlers), and all that remained was to find a way to
>> advertise the capability.
>>
>> A conversation at SambaXP with Metze, Steve, Tridge concluded that
>> the new "who am I" and the "extattr" operations set a good precedent
>> for using the unix capabilities bit and a new info level in the unix
>> capabilities to advertise the proxy capabilities (I think I got that
>> mostly right). (And a different advertisment method would be needed
>> for a windows implementation but Tridge knew what that was, I forget).
>>
>> The actual operations and their definitions are quite fluid at the
>> moment but the current definitions can be had at:
>> http://repo.or.cz/w/Samba/vfs_proxy.git?a=blob;f=source/librpc/idl/proxy.idl;h=f54c5ac8ecd24d01c01de64db6e5502218b0598c;hb=v4-0-vfs-proxy
>>
>
> So each proxy operation maps to an ioctl operation? Or does the ioctl
> interface simple do transact/read/write?
There is one ioctl which implements an rpc-lite interface as the ioctl
payload consists of a GUID, an operation number and then some NDR. The
response consists of NDR.

The current proxy interface is just handled by functions of one
particular GUID.
>
>> You will see that currently there is defined is an extended read and
>> extended write operation that make use of cache and compression
>> between proxies to avoid sending the full read response where possible.
>>
>> There are no stricter definitions or specifications and that
>> interface will change in the near future to include different
>> cache-based compression techniques;
>
> I'm guessing that the ioctl interface you define is a multiplexor? In
> that case, you should add an operation that allows capability
> negotiation or versioning so that you don't need to burn an more UNIX
> capability bits when your feature set changes.

This is a good suggestion; I will do this with specific rpc-lite GUID
and simple IDL so that the negotiation could easily take place without
NDR in systems where that is convenient.

>
>> but a review of the irc comments by samjam and the mailing list posts
>> of Amin Azez will reveal a lot more on the subject. The SambaXP
>> slides ought to be up text week sometime I suppose.
>
> Any idea whether there will be audio or video available?
>

I'm posting my slides to SerNet this morning. When audio is available
from SerNet I will overlay it on the slides and post those.

Sam


More information about the samba-technical mailing list