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

Пн Окт 19 10:44:43 MSD 2009

Здравствуйте,

высылаю цепочку обсуждения новой особенности CIFS, которую предлагали
разработчики Wine. Прошу посмотреть и, если можно, прокомментировать, что вы
об этом думаете.

Forwarded conversation
Subject: [linux-cifs-client] [patch][0/3] Add support infrastructure for
Named Pipe
------------------------

From: *Shirish Pargaonkar* <shirishpargaonkar на gmail.com>
Date: 2009/10/15
To: linux-cifs-client на lists.samba.org, linux-fsdevel <
linux-fsdevel на vger.kernel.org>

Add Named Pipe support in cifs client.

Since there are no equivalent kernel APIs for transactions, most of the
SMBTrans
functions are implemented using ioctls which are handle based, like the
APIs used for Named Pipes.

A path based function, WaitNamedPipe is not implemented at this time.
Also not implemented support for multiple fragments in TransactNmPipe
function.

Signed-off-by: Shirish Pargaonkar shirishpargaonkar на gmail.com

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client на lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client

----------
From: *Jeff Layton* <jlayton на redhat.com>
Date: 2009/10/15
To: Shirish Pargaonkar <shirishpargaonkar на gmail.com>
Cc: linux-fsdevel <linux-fsdevel на vger.kernel.org>,
linux-cifs-client на lists.samba.org

The downsides of doing this in kernel seem to outweigh the advantages.
Here's my reasoning...

This is something that is far, far better done in userspace. Lets be
clear here -- the only user of this support that has ever been
identified is WINE. Why would it not be better to have this either
implemented directly by WINE or handled by another userspace service?

The only reason I've heard so far that anyone wants to do this in
the kernel is for licensing reasons. WINE is LGPLv2 and libsmbclient
is GPLv3, so WINE can't really use libsmbclient. This strikes me as a
very bad reason to put this infrastructure in the kernel. A standalone
userspace daemon that implements this seems like a better way to deal
with the licensing problems.

If you do this in a userspace daemon, then you're also not constrained
by a VFS interface, and won't need to do ugly stuff like implement
ioctls for calls that don't exist in Linux. Have WINE talk to the
daemon using a standard IPC mechanism (maybe a FIFO or unix socket?),
and have the daemon turn those into on the wire SMB calls.

It's also not clear to me how you're going to hook WINE up to this
plumbing. You'll need infrastructure too to actually handle doing some
sort of implicit "mount" of an IPC$ share when WINE wants to talk to a
new host (there is no guarantee that you'll have an existing CIFS mount
to this 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?
How will credentials be handled?

Again, this is something much easier to handle with an all-userspace
solution. A userspace daemon can talk to winbind et. al. and deal with
creds that way.

--
Jeff Layton <jlayton на redhat.com>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client на lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client

----------
From: *Steve French* <smfrench на gmail.com>
Date: 2009/10/16
To: linux-cifs-client на lists.samba.org
Cc: Jeff Layton <jlayton на redhat.com>

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.

> 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).
> 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
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.

--
Thanks,

Steve

----------
From: *Jeff Layton* <jlayton на redhat.com>
Date: 2009/10/16
To: Steve French <smfrench на gmail.com>
Cc: linux-cifs-client на lists.samba.org

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.
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.

----------
From: *Shirish Pargaonkar* <shirishpargaonkar на gmail.com>
Date: 2009/10/16
To: Jeff Layton <jlayton на redhat.com>
Cc: Steve French <smfrench на gmail.com>, linux-cifs-client на lists.samba.org

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)?

> --

----------
From: *Volker Lendecke* <Volker.Lendecke на sernet.de>
Date: 2009/10/16
To: Shirish Pargaonkar <shirishpargaonkar на gmail.com>
Cc: Steve French <smfrench на gmail.com>, linux-cifs-client на lists.samba.org,
Jeff Layton <jlayton на redhat.com>

Regarding the credentials: Either you have Kerberos, or for
NTLM winbind can provide a credential store. If anything
does not work sufficiently with winbind, we will fix it.

Volker

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrYaMkACgkQbsgDfmnSbrZhmwCfXBwaeNep53Is0h3PlVoplHJn
OOUAn1aphn+U3JUSCw3RNjyQSOOVN6AC
=u7JJ
-----END PGP SIGNATURE-----

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client на lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client

----------
From: *Steve French* <smfrench на gmail.com>
Date: 2009/10/16
To: Jeff Layton <jlayton на redhat.com>
Cc: linux-cifs-client на lists.samba.org

Not sure I would describe adding two or three SMB calls "shoving code into
the kernel" especially as this in kernel in most other OS and fits with
the kernel layer.   Remember that no one is suggesting adding DCOM
and RPC to kernel - just the ability to do a couple missing primitives
(e.g. transact and setnmpstate) which makes the user space code eaiser.
It seems insane to creating a dependency on a userspace daemon
which has to hang around just to avoid adding a couple of wire requests
(especially since these transact calls aren't really written in userspace
this way).  Even with  userspace IPC to a GPL daemon I have heard concerns
that that is frowned upon (IANAL).
I am not suggesting that we give WINE elevated priv.

--
Thanks,

Steve

----------
From: *Steve French* <smfrench на gmail.com>
Date: 2009/10/16
To: Volker.Lendecke на sernet.de
Cc: linux-cifs-client на lists.samba.org, Jeff Layton <jlayton на redhat.com>

Yes.  That is excellent.   I think the issue of getting
credentials is independent though of whether to add the missing
SMB to the kernel though.

--
Thanks,

Steve

----------
From: *Jeff Layton* <jlayton на redhat.com>
Date: 2009/10/16
To: Shirish Pargaonkar <shirishpargaonkar на gmail.com>
Cc: Steve French <smfrench на gmail.com>, linux-cifs-client на lists.samba.org

On Fri, 16 Oct 2009 07:26:20 -0500
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?

--

----------
From: *Jeff Layton* <jlayton на redhat.com>
Date: 2009/10/16
To: Steve French <smfrench на gmail.com>
Cc: linux-cifs-client на lists.samba.org

On Fri, 16 Oct 2009 07:35:33 -0500
I don't think it's insane at all. It seems perfectly reasonable to have
a standalone CIFS named pipe service daemon rather than doing this in
kernel.

IANAL either, but I don't see how this would be any different
than talking to any other general-purpose service (syslog or the
resolver, for instance). To my understanding, whether this code is in
kernel or userspace is somewhat irrelevant as long as you're not
linking to it.

Either way...I think we should focus on the best technical solution for
this and worry about licensing once we settle on that.
But you are. Something has to mount this IPC$ share, right? CIFS only
open sockets to servers when someone does an actual mount. This
patchset doesn't change that.

Again, it's very difficult to discuss this without understanding how
you intend for userspace to actually use this support. Can you outline
how you envision userspace programs using this new code?

--

----------
From: *Christoph Hellwig* <hch на infradead.org>
Date: 2009/10/19
To: Jeff Layton <jlayton на redhat.com>
Cc: Steve French <smfrench на gmail.com>, linux-cifs-client на lists.samba.org

Yeah.  I have no problem adding kernel support for the named pipes to
the kernel if we really need to, but:

 - please odn't shove it into a filesystem as that's a totally unrelated
  abstraction
 - write some proper code for it, not the thing that was submitted
  adding random ioctls dereferecing user pointers and similar.
  Incidentally moving it out of cifs will make that a lot easier as
  bad code doesn't really stick out in cifs.

----------
From: *Steve French* <smfrench на gmail.com>
Date: 2009/10/19
To: Christoph Hellwig <hch на infradead.org>
Cc: linux-cifs-client на lists.samba.org, Jeff Layton <jlayton на redhat.com>

Problem with making them via something other than an ioctl is -
they are handle based ops and operations on pipes
are the same on the wire as open/close/read/write
operations on files so the majority of this already works (these
are the client not server side of pipe operations Shirish
is talking about).   The missing operations
are handle based (e.g. transact and get/set named pipe info)
so ioctls seem reasonable and  I don't know of an obvious
alternative to ioctl, to do handle based operations.   Certainly it is much
smaller to do a few ioctls  than the alternatives and the ioctls can easily
be hidden by a user space library as apparently
Shirish did in a prototype and saves having to write a new cifs client
from scratch.

A quick search shows that the idea of having ioctls for special
purpose pipe operations (Unix pipes and Windows pipes) is
not new, it seems to have been done before on multiple platforms.
(includ

--
Thanks,

Steve

-- 
Sin (Sinelnikov Evgeny)
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.etersoft.ru/pipermail/devel/attachments/20091019/c799c164/attachment-0001.html>