<div dir="ltr"><div dir="ltr">Thanks Even</div><div dir="ltr"><br></div><div>That sounds like a possible path forward, although it works for FUSE filesystems only, so we'd have to find a good FUSE implementation of CIFS (currently we're using the kernel provided cifs)</div><div><br></div><div>If anyone can recommend a well-maintained FUSE CIFS implementation I'd gladly look into it. After some googling I don't see much that fills me with confidence, but I will continue to search at work next week.<br></div><div><br></div><div>I'll keep you updated on what I discover. Thanks</div><div>Craig<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Dec 2019 at 23:38, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Craig,<br>
<br>
> We have to access some customer data via their CIFS shares on a regular<br>
> basis.<br>
> <br>
> To date we have been doing it via a setuid script which mounts and unmounts<br>
> the CIFS share locally, then treats the files as local. We're<br>
> containerising our workers, and using kernel mounts is no longer possible<br>
> (at least, not even slightly securely.)<br>
<br>
Is upgrading to Kernel 4.18 an option ?<br>
See <a href="https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18-FUSE" rel="noreferrer" target="_blank">https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18-FUSE</a><br>
<br>
> <br>
> This means we need a userspace CIFS implementation for a lot of our GDAL<br>
> code, and a VSI CIFS driver would seem to be the right thing to do.<br>
> Presumably it will be a fairly thin wrapper of libsmb.<br>
> <br>
> 2. Would it be something GDAL might accept as a core contribution, or<br>
> should we expect to maintain it outside of core?<br>
<br>
Hard to know where to draw the line. If recent kernels would make this no <br>
longer needed, then its value in core might be low.<br>
<br>
> 3. We noticed <a href="https://github.com/OSGeo/gdal/pull/1289" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/pull/1289</a> should allow VSI<br>
> plugins to be registered from Python,<br>
<br>
It allows VSI plugins to be registered with a C interface. So if you'd want ot <br>
use that from Python, you'd likely have to play with ctypes or similar <br>
technology.<br>
<br>
> Are there any docs on how to actually do this?<br>
<br>
Well, the Doxygen docs of VSIAllocFilesystemPluginCallbacksStruct and <br>
VSIInstallPluginHandler in cpl_vsi.h . And the tutorial you'll add if you <br>
proceed that way ;-)<br>
<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Regards,</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Craig</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Developer</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Koordinates</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><a href="tel:+64%2021%20256%209488" style="color:rgb(17,85,204)" target="_blank">+64 21 256 9488</a> / <a href="http://koordinates.com/" style="color:rgb(17,85,204)" target="_blank">koordinates.com</a> / <a href="https://twitter.com/koordinates" style="color:rgb(17,85,204)" target="_blank">@koordinates</a></div></div></div></div>