[linux-cifs-client] Add support infrastructure for Named Pipe

[Shirish Pargaonkar]

On Fri, Oct 16, 2009 at 7:06 AM, Jeff Layton <jlayton at redhat.com> wrote:
> On Thu, 15 Oct 2009 18:55:57 -0500
> Steve French <smfrench at gmail.com> wrote:
>
>> > the only user of this support that has ever been identified is WINE.
>> I have had requests over the years for adding the few missing calls,
>> from a lot more than from WINE.  Various distros have to ship multiple
>> versions of Samba with conflicting licenses to work around problems in
>> desktops, and the libsmbclient is not appropriate for everyone. For a
>> while it looked like Centeris/Likewise would address some of the need
>> (presumably not an option for most distros though) but even with that
>> it is messy to have userspace making connections when kernel code
>> already has a connection to the same server.
>>
>
> Shoving code into the kernel to work around licensing problems is not a
> good solution. All of those problems can equally be solved by a daemon
> that runs in userspace.
>
> I'm not of the opinion that an extra connection to the server is a huge
> deal. At least, not a big enough problem to warrant doing this in
> kernel rather than in userspace.
>
>> > I don't think this stuff has any place in the kernel.  Just implement the named pipes directly in wine.
>> I agree that all code that is above the SMB/CIFS layer could (and
>> should) be put in user space (probably in a new helper library, since
>> Samba currently doesn't have anything which matches exactly, and I
>> have seen requests from others over the last few years for something
>> like what Centeris was trying to do with librpc for dcom over pipes),
>> but it doesn't make much sense to reimplement another cifs client in
>> user space, when pipe operations use (mostly) read and write SMBs.
>> As far as I can tell, there are only a couple of additional SMBs that
>> this patch suggests adding and it looks straightforward, and much much
>> easier than adding a whole new SMB/CIFS client in user space.   CIFS
>> already had support for mounting to IPC$ shares and opening a pipe
>> (pipes are similar to file objects), but it turns out that for a
>> userspace library to take advantage of that it is helpful to add
>> transact and two other ioctls.   Seems much easier to do it this way,
>> and will avoid having to renegotiate multiple tcp sockets from the
>> same client (which conserves server resources).
>>
>> > You'll need infrastructure too to actually handle doing some
>> > sort of implicit "mount" of an IPC$ share when ...
>> > new host What's going to trigger the "mount" the IPC$ share? What if I have
>> > multiple users on the same host that want to talk to the same server?
>>
>> We have to do that (automatic session setup if we don't have an smb uid
>> for this uid) anyway in cifs.ko (just as NFS has to autoconnect).
>> Today (in cifs), we use the credentials that match the pid (if we know
>> them, and use the default if we don't).   This needs to be fixed
>> to allow obtaining credentials from userspace (whether or not
>> pipe support is added) so is a different issue.
>>
>> Since this patch is fairly small, and the smbs fit with what cifs already does,
>> I think it makes sense.   The userspace DCE/RPC code (which Shirish has
>> prototyped and tried various versions of) is the majority of the code, but
>> doesn't have to go in kernel - would go in a new Samba lib presumably.
>>
>>
>>
>
> Just because CIFS has part of the code needed to this already doesn't
> mean that it's the right place to do this. I'm sure that libsmbclient
> or the Likewise stuff has a good portion of what is needed already too.
>
> One thing I haven't yet heard is how you expect WINE to actually use
> this stuff. As I noted before, there is no guarantee that you will know
> what hosts WINE wants to talk to before you start it up. Therefore you
> can't know beforehand what IPC$ mounts you will need.
>
> With what you have so far, WINE will need to mount the IPC$
> share in order to use it. I personally am not comfortable with a
> solution that requires giving WINE the elevated privileges that it will
> need in order to actually do this mount. Doing this in userspace is
> better and safer for that reason alone.
>

Do we need to have a mount i.e. would a tree connection to IPC$ share suffice
for a WINE app user id by obtaining credentials for that user id via cifs upcall
using a arbitrary security mechanism when that user very first time accesses
a named pipe (e.g. during CreateFile)?

> --
> Jeff Layton <jlayton at redhat.com>
>