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

[Jeff Layton]

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.

-- 
Jeff Layton <jlayton at redhat.com>