[gdal-dev] VSI CIFS driver

[Craig de Stigter]

Sorry, that's `fusesmb`, not `smbfuse`

On Mon, 16 Dec 2019 at 15:40, Craig de Stigter <
craig.destigter at koordinates.com> wrote:

> I haven't quite exhausted my frustration budget for this yet but here's
> what I've found so far:
>
>
>    - `smbfuse` appears to be abandoned since 2007, though Ubuntu is still
>    packaging it through 19.10.
>    - I can't really find anything else in this space.
>    - To use FUSE at all you need the `fuse` module, which isn't enabled
>    in any of the default images I tried.
>    - Some systems don't seem to support loading kernel modules, e.g. the
>    xhyve VM on Docker for Desktop (well, the Mac version anyway) doesn't seem
>    to allow `modprobe`
>
> I think it's probably more straightforward to implement a VSI CIFS than a
> FUSE CIFS.
>
>
>
> On Sat, 14 Dec 2019 at 20:42, Craig de Stigter <
> craig.destigter at koordinates.com> wrote:
>
>> Thanks Even
>>
>> 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)
>>
>> 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.
>>
>> I'll keep you updated  on what I discover. Thanks
>> Craig
>>
>> On Fri, 13 Dec 2019 at 23:38, Even Rouault <even.rouault at spatialys.com>
>> wrote:
>>
>>> Craig,
>>>
>>> > We have to access some customer data via their CIFS shares on a regular
>>> > basis.
>>> >
>>> > To date we have been doing it via a setuid script which mounts and
>>> unmounts
>>> > the CIFS share locally, then treats the files as local. We're
>>> > containerising our workers, and using kernel mounts is no longer
>>> possible
>>> > (at least, not even slightly securely.)
>>>
>>> Is upgrading to Kernel 4.18 an option ?
>>> See https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18-FUSE
>>>
>>> >
>>> > This means we need a userspace CIFS implementation for a lot of our
>>> GDAL
>>> > code, and a VSI CIFS driver would seem to be the right thing to do.
>>> > Presumably it will be a fairly thin wrapper of libsmb.
>>> >
>>> > 2. Would it be something GDAL might accept as a core contribution, or
>>> > should we expect to maintain it outside of core?
>>>
>>> Hard to know where to draw the line. If recent kernels would make this
>>> no
>>> longer needed, then its value in core might be low.
>>>
>>> > 3. We noticed https://github.com/OSGeo/gdal/pull/1289 should allow VSI
>>> > plugins to be registered from Python,
>>>
>>> It allows VSI plugins to be registered with a C interface. So if you'd
>>> want ot
>>> use that from Python, you'd likely have to play with ctypes or similar
>>> technology.
>>>
>>> > Are there any docs on how to actually do this?
>>>
>>> Well, the Doxygen docs of VSIAllocFilesystemPluginCallbacksStruct and
>>> VSIInstallPluginHandler in cpl_vsi.h . And the tutorial you'll add if
>>> you
>>> proceed that way ;-)
>>>
>>>
>>> Even
>>>
>>> --
>>> Spatialys - Geospatial professional services
>>> http://www.spatialys.com
>>>
>>
>>
>> --
>> Regards,
>> Craig
>>
>> Developer
>> Koordinates
>>
>> +64 21 256 9488 <+64%2021%20256%209488> / koordinates.com / @koordinates
>> <https://twitter.com/koordinates>
>>
>
>
> --
> Regards,
> Craig
>
> Developer
> Koordinates
>
> +64 21 256 9488 <+64%2021%20256%209488> / koordinates.com / @koordinates
> <https://twitter.com/koordinates>
>


-- 
Regards,
Craig

Developer
Koordinates

+64 21 256 9488 <+64%2021%20256%209488> / koordinates.com / @koordinates
<https://twitter.com/koordinates>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191216/87e869c3/attachment.html>