úÄÒÁ×ÓÔ×ÕÊÔÅ,<br><br>×ÙÓÙÌÁÀ ÃÅÐÏÞËÕ ÏÂÓÕÖÄÅÎÉÑ ÎÏ×ÏÊ ÏÓÏÂÅÎÎÏÓÔÉ CIFS, ËÏÔÏÒÕÀ ÐÒÅÄÌÁÇÁÌÉ ÒÁÚÒÁÂÏÔÞÉËÉ Wine. ðÒÏÛÕ ÐÏÓÍÏÔÒÅÔØ É, ÅÓÌÉ ÍÏÖÎÏ, ÐÒÏËÏÍÍÅÎÔÉÒÏ×ÁÔØ, ÞÔÏ ×Ù Ï ÜÔÏÍ ÄÕÍÁÅÔÅ.<br><br><br><div class="gmail_quote"><span style="font-size: large; font-weight: bold;">Forwarded conversation</span><br>
Subject: <b class="gmail_sendername">[linux-cifs-client] [patch][0/3] Add support infrastructure for Named Pipe</b><br>------------------------<br><br><span class="undefined"><font color="#000000">From: <b class="undefined">Shirish Pargaonkar</b> <span dir="ltr"><<a href="mailto:shirishpargaonkar@gmail.com">shirishpargaonkar@gmail.com</a>></span><br>
Date: 2009/10/15<br>To: <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a>, linux-fsdevel <<a href="mailto:linux-fsdevel@vger.kernel.org">linux-fsdevel@vger.kernel.org</a>><br>
</font><br>
</span><br><div>Add Named Pipe support in cifs client.š </div>
<div>š</div>
<div>Since there are no equivalent kernel APIs for transactions, most of the SMBTrans</div>
<div>functions are implemented using ioctls which are handle based, like the </div>
<div>APIs used for Named Pipes.</div>
<div>š</div>
<div>A path based function, WaitNamedPipe is not implemented at this time.</div>
<div>Also not implemented support for multiple fragments in TransactNmPipe function.</div>
<div>š</div>
<div>š</div>
<div>Signed-off-by: Shirish Pargaonkar <a href="mailto:shirishpargaonkar@gmail.com" target="_blank">shirishpargaonkar@gmail.com</a></div>
<br>_______________________________________________<br>
linux-cifs-client mailing list<br>
<a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br>
<a href="https://lists.samba.org/mailman/listinfo/linux-cifs-client" target="_blank">https://lists.samba.org/mailman/listinfo/linux-cifs-client</a><br>
<br><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Jeff Layton</b> <span dir="ltr"><<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>></span><br>Date: 2009/10/15<br>
To: Shirish Pargaonkar <<a href="mailto:shirishpargaonkar@gmail.com">shirishpargaonkar@gmail.com</a>><br>Cc: linux-fsdevel <<a href="mailto:linux-fsdevel@vger.kernel.org">linux-fsdevel@vger.kernel.org</a>>, <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br>
</font><br></span><br>The downsides of doing this in kernel seem to outweigh the advantages.<br>
Here's my reasoning...<br>
<br>
This is something that is far, far better done in userspace. Lets be<br>
clear here -- the only user of this support that has ever been<br>
identified is WINE. Why would it not be better to have this either<br>
implemented directly by WINE or handled by another userspace service?<br>
<br>
The only reason I've heard so far that anyone wants to do this in<br>
the kernel is for licensing reasons. WINE is LGPLv2 and libsmbclient<br>
is GPLv3, so WINE can't really use libsmbclient. This strikes me as a<br>
very bad reason to put this infrastructure in the kernel. A standalone<br>
userspace daemon that implements this seems like a better way to deal<br>
with the licensing problems.<br>
<br>
If you do this in a userspace daemon, then you're also not constrained<br>
by a VFS interface, and won't need to do ugly stuff like implement<br>
ioctls for calls that don't exist in Linux. Have WINE talk to the<br>
daemon using a standard IPC mechanism (maybe a FIFO or unix socket?),<br>
and have the daemon turn those into on the wire SMB calls.<br>
<br>
It's also not clear to me how you're going to hook WINE up to this<br>
plumbing. You'll need infrastructure too to actually handle doing some<br>
sort of implicit "mount" of an IPC$ share when WINE wants to talk to a<br>
new host (there is no guarantee that you'll have an existing CIFS mount<br>
to this host).<br>
<br>
What's going to trigger the "mount" the IPC$ share? What if I have<br>
multiple users on the same host that want to talk to the same server?<br>
How will credentials be handled?<br>
<br>
Again, this is something much easier to handle with an all-userspace<br>
solution. A userspace daemon can talk to winbind et. al. and deal with<br>
creds that way.<br>
<font color="#888888"><br>
--<br>
Jeff Layton <<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>><br>
_______________________________________________<br>
linux-cifs-client mailing list<br>
<a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br>
<a href="https://lists.samba.org/mailman/listinfo/linux-cifs-client" target="_blank">https://lists.samba.org/mailman/listinfo/linux-cifs-client</a><br>
</font><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Steve French</b> <span dir="ltr"><<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>></span><br>Date: 2009/10/16<br>
To: <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br>Cc: Jeff Layton <<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>><br></font><br></span><br>I have had requests over the years for adding the few missing calls,<br>
from a lot more than from WINE. šVarious distros have to ship multiple<br>
versions of Samba with conflicting licenses to work around problems in<br>
desktops, and the libsmbclient is not appropriate for everyone. šFor a<br>
while it looked like Centeris/Likewise would address some of the need<br>
(presumably not an option for most distros though) but even with that<br>
it is messy to have userspace making connections when kernel code<br>
already has a connection to the same server.<br>
<br>
> I don't think this stuff has any place in the kernel. šJust implement the named pipes directly in wine.<br>
I agree that all code that is above the SMB/CIFS layer could (and<br>
should) be put in user space (probably in a new helper library, since<br>
Samba currently doesn't have anything which matches exactly, and I<br>
have seen requests from others over the last few years for something<br>
like what Centeris was trying to do with librpc for dcom over pipes),<br>
but it doesn't make much sense to reimplement another cifs client in<br>
user space, when pipe operations use (mostly) read and write SMBs.<br>
As far as I can tell, there are only a couple of additional SMBs that<br>
this patch suggests adding and it looks straightforward, and much much<br>
easier than adding a whole new SMB/CIFS client in user space. š CIFS<br>
already had support for mounting to IPC$ shares and opening a pipe<br>
(pipes are similar to file objects), but it turns out that for a<br>
userspace library to take advantage of that it is helpful to add<br>
transact and two other ioctls. š Seems much easier to do it this way,<br>
and will avoid having to renegotiate multiple tcp sockets from the<br>
same client (which conserves server resources).<br>
> sort of implicit "mount" of an IPC$ share when ...<br>
> new host What's going to trigger the "mount" the IPC$ share? What if I have<br>
We have to do that (automatic session setup if we don't have an smb uid<br>
for this uid) anyway in cifs.ko (just as NFS has to autoconnect).<br>
Today (in cifs), we use the credentials that match the pid (if we know<br>
them, and use the default if we don't). š This needs to be fixed<br>
to allow obtaining credentials from userspace (whether or not<br>
pipe support is added) so is a different issue.<br>
<br>
Since this patch is fairly small, and the smbs fit with what cifs already does,<br>
I think it makes sense. š The userspace DCE/RPC code (which Shirish has<br>
prototyped and tried various versions of) is the majority of the code, but<br>
doesn't have to go in kernel - would go in a new Samba lib presumably.<br>
<br>
<br>
<br>
--<br>
Thanks,<br>
<font color="#888888"><br>
Steve<br>
</font><div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Jeff Layton</b> <span dir="ltr"><<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>></span><br>
Date: 2009/10/16<br>To: Steve French <<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>><br>Cc: <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br></font><br></span><br>
Shoving code into the kernel to work around licensing problems is not a<br>
good solution. All of those problems can equally be solved by a daemon<br>
that runs in userspace.<br>
<br>
I'm not of the opinion that an extra connection to the server is a huge<br>
deal. At least, not a big enough problem to warrant doing this in<br>
kernel rather than in userspace.<br>
<div><div></div></div>Just because CIFS has part of the code needed to this already doesn't<br>
mean that it's the right place to do this. I'm sure that libsmbclient<br>
or the Likewise stuff has a good portion of what is needed already too.<br>
<br>
One thing I haven't yet heard is how you expect WINE to actually use<br>
this stuff. As I noted before, there is no guarantee that you will know<br>
what hosts WINE wants to talk to before you start it up. Therefore you<br>
can't know beforehand what IPC$ mounts you will need.<br>
<br>
With what you have so far, WINE will need to mount the IPC$<br>
share in order to use it. I personally am not comfortable with a<br>
solution that requires giving WINE the elevated privileges that it will<br>
need in order to actually do this mount. Doing this in userspace is<br>
better and safer for that reason alone.<br>
<div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Shirish Pargaonkar</b> <span dir="ltr"><<a href="mailto:shirishpargaonkar@gmail.com">shirishpargaonkar@gmail.com</a>></span><br>
Date: 2009/10/16<br>To: Jeff Layton <<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>><br>Cc: Steve French <<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>>, <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br>
</font><br></span><br><div><div></div></div>Do we need to have a mount i.e. would a tree connection to IPC$ share suffice<br>
for a WINE app user id by obtaining credentials for that user id via cifs upcall<br>
using a arbitrary security mechanism when that user very first time accesses<br>
a named pipe (e.g. during CreateFile)?<br>
<br>
> --<br>
<div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Volker Lendecke</b> <span dir="ltr"><<a href="mailto:Volker.Lendecke@sernet.de">Volker.Lendecke@sernet.de</a>></span><br>
Date: 2009/10/16<br>To: Shirish Pargaonkar <<a href="mailto:shirishpargaonkar@gmail.com">shirishpargaonkar@gmail.com</a>><br>Cc: Steve French <<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>>, <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a>, Jeff Layton <<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>><br>
</font><br></span><br>Regarding the credentials: Either you have Kerberos, or for<br>
NTLM winbind can provide a credential store. If anything<br>
does not work sufficiently with winbind, we will fix it.<br>
<font color="#888888"><br>
Volker<br>
</font><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
<br>
iEYEARECAAYFAkrYaMkACgkQbsgDfmnSbrZhmwCfXBwaeNep53Is0h3PlVoplHJn<br>
OOUAn1aphn+U3JUSCw3RNjyQSOOVN6AC<br>
=u7JJ<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
linux-cifs-client mailing list<br>
<a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br>
<a href="https://lists.samba.org/mailman/listinfo/linux-cifs-client" target="_blank">https://lists.samba.org/mailman/listinfo/linux-cifs-client</a><br>
<br><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Steve French</b> <span dir="ltr"><<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>></span><br>Date: 2009/10/16<br>
To: Jeff Layton <<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>><br>Cc: <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br></font><br></span><br>Not sure I would describe adding two or three SMB calls "shoving code into<br>
the kernel" especially as this in kernel in most other OS and fits with<br>
the kernel layer. š Remember that no one is suggesting adding DCOM<br>
and RPC to kernel - just the ability to do a couple missing primitives<br>
(e.g. transact and setnmpstate) which makes the user space code eaiser.<br>
It seems insane to creating a dependency on a userspace daemon<br>
which has to hang around just to avoid adding a couple of wire requests<br>
(especially since these transact calls aren't really written in userspace<br>
this way). šEven with šuserspace IPC to a GPL daemon I have heard concerns<br>
that that is frowned upon (IANAL).<br>
I am not suggesting that we give WINE elevated priv.<br>
<br>
<br>
--<br>
Thanks,<br>
<font color="#888888"><br>
Steve<br>
</font><div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Steve French</b> <span dir="ltr"><<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>></span><br>
Date: 2009/10/16<br>To: <a href="mailto:Volker.Lendecke@sernet.de">Volker.Lendecke@sernet.de</a><br>Cc: <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a>, Jeff Layton <<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>><br>
</font><br></span><br><div><div></div></div>Yes. šThat is excellent. š I think the issue of getting<br>
credentials is independent though of whether to add the missing<br>
SMB to the kernel though.<br>
<br>
<br>
<br>
--<br>
Thanks,<br>
<font color="#888888"><br>
Steve<br>
</font><div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Jeff Layton</b> <span dir="ltr"><<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>></span><br>
Date: 2009/10/16<br>To: Shirish Pargaonkar <<a href="mailto:shirishpargaonkar@gmail.com">shirishpargaonkar@gmail.com</a>><br>Cc: Steve French <<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>>, <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br>
</font><br></span><br>On Fri, 16 Oct 2009 07:26:20 -0500<br>
<div><div></div></div>Well...all of this code seems to presuppose that there will be actual<br>
filesystem objects on which to operate. IOW, you can't call an ioctl on<br>
a non-existent filehandle.<br>
<br>
Again, it's not at all clear from this patchset how userspace will<br>
actually use this code. How do you envision userspace programs actually<br>
making use of this?<br>
<font color="#888888"><br>
--<br>
</font><div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Jeff Layton</b> <span dir="ltr"><<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>></span><br>
Date: 2009/10/16<br>To: Steve French <<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>><br>Cc: <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br></font><br></span><br>
On Fri, 16 Oct 2009 07:35:33 -0500<br>
I don't think it's insane at all. It seems perfectly reasonable to have<br>
a standalone CIFS named pipe service daemon rather than doing this in<br>
kernel.<br>
<br>
IANAL either, but I don't see how this would be any different<br>
than talking to any other general-purpose service (syslog or the<br>
resolver, for instance). To my understanding, whether this code is in<br>
kernel or userspace is somewhat irrelevant as long as you're not<br>
linking to it.<br>
<br>
Either way...I think we should focus on the best technical solution for<br>
this and worry about licensing once we settle on that.<br>
But you are. Something has to mount this IPC$ share, right? CIFS only<br>
open sockets to servers when someone does an actual mount. This<br>
patchset doesn't change that.<br>
<br>
Again, it's very difficult to discuss this without understanding how<br>
you intend for userspace to actually use this support. Can you outline<br>
how you envision userspace programs using this new code?<br>
<font color="#888888"><br>
--<br>
</font><div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Christoph Hellwig</b> <span dir="ltr"><<a href="mailto:hch@infradead.org">hch@infradead.org</a>></span><br>
Date: 2009/10/19<br>To: Jeff Layton <<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>><br>Cc: Steve French <<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>>, <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br>
</font><br></span><br>Yeah. šI have no problem adding kernel support for the named pipes to<br>
the kernel if we really need to, but:<br>
<br>
š- please odn't shove it into a filesystem as that's a totally unrelated<br>
š abstraction<br>
š- write some proper code for it, not the thing that was submitted<br>
š adding random ioctls dereferecing user pointers and similar.<br>
š Incidentally moving it out of cifs will make that a lot easier as<br>
š bad code doesn't really stick out in cifs.<br>
<div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Steve French</b> <span dir="ltr"><<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>></span><br>
Date: 2009/10/19<br>To: Christoph Hellwig <<a href="mailto:hch@infradead.org">hch@infradead.org</a>><br>Cc: <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a>, Jeff Layton <<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>><br>
</font><br></span><br>Problem with making them via something other than an ioctl is -<br>
they are handle based ops and operations on pipes<br>
are the same on the wire as open/close/read/write<br>
operations on files so the majority of this already works (these<br>
are the client not server side of pipe operations Shirish<br>
is talking about). š The missing operations<br>
are handle based (e.g. transact and get/set named pipe info)<br>
so ioctls seem reasonable and šI don't know of an obvious<br>
alternative to ioctl, to do handle based operations. š Certainly it is much<br>
smaller to do a few ioctls šthan the alternatives and the ioctls can easily<br>
be hidden by a user space library as apparently<br>
Shirish did in a prototype and saves having to write a new cifs client<br>
from scratch.<br>
<br>
A quick search shows that the idea of having ioctls for special<br>
purpose pipe operations (Unix pipes and Windows pipes) is<br>
not new, it seems to have been done before on multiple platforms.<br>
(includ<br>
<br>
<br>
--<br>
Thanks,<br>
<font color="#888888"><br>
Steve<br>
</font><div><div></div></div><br></div><br><br clear="all"><br>-- <br>Sin (Sinelnikov Evgeny)<br>