Re: Add support infrastructure for Named Pipe

On Fri, 16 Oct 2009 07:26:20 -0500
Shirish Pargaonkar <[email protected]> wrote:

> On Fri, Oct 16, 2009 at 7:06 AM, Jeff Layton <[email protected]> wrote:
> > On Thu, 15 Oct 2009 18:55:57 -0500
> > Steve French <[email protected]> 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)?
> 

Well...all of this code seems to presuppose that there will be actual
filesystem objects on which to operate. IOW, you can't call an ioctl on
a non-existent filehandle.

Again, it's not at all clear from this patchset how userspace will
actually use this code. How do you envision userspace programs actually
making use of this?

-- 
Jeff Layton <[email protected]>