[conspire] access to network drive - denies to root?

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [conspire] access to network drive - denies to root?
> Date: Wed, 8 Jul 2020 20:40:03 -0700

> Quoting tom r lopes (tomrlopes at gmail.com):
>
>> https://assets.ctfassets.net/0lvk5dbamxpi/6jBxT5LDgMqutNK4mPTGKd/4fa27cb4a130bca3b48a10c9045b0497/draft-ietf-secsh-filexfer-02
>
> Is this an elaborate way of saying 'Ruben, just use sftp'?
>
> If so, sftp (a network protocol for browsing and retrieving files over
> an ssh channel) is not very comparable to sshfs (a remote filesystem
> operating over ssh transport).

As far as I'm aware, sshfs just uses sftp under the covers.  Basically
that and fuse.

> Ruben:  I'm just catching up on this thread, but I have to tell you,
> this is the first time I've encountered someone trying to deploy sshfs
> in twenty years.  You may have a difficult time getting knowledgeable
> help, for lack of significant numbers of users.

Other than sshfs sounding quite, uh, "interesting" - but mostly lacking
use case(s), I think I only once bumped into a use case where it was
quite warranted ... and only relatively temporarily at that.
If I recall correctly, it went about like this:

Was dealing, at $work, with a vendor.  This vendor was highly probable
to go belly-up or disappear in the not-too-horribly-distant-future (think
general incompetence and poor quality software, etc.).  Unfortunately
we were still running this crud, and at least at the time relatively
dependent upon it - and likely to continue to be for at least some
moderate while (months ... year(s?)) to come.  So ... support ...
we wanted to download *all* of the support files and documentation
from their site ... at least anything at all that did or might matter
to us and that we did or may care about.  And, for the most part,
all of this was offered to us, from the vendor's site - only via
sftp - not https, not ssh, not ftp, just sftp.  And a fairly deep
hierarchy of directories, and lots of files in various directories,
etc.  Sure, it could be done (semi-)manually with sftp.  But that
would be a pain, take quite a bit of time, and be potentially quite
error prone and difficult to verify if it was all done and done
correctly.

Well, if I recall correctly, I did a wee bit 'o research, and found
and put to use sshfs.  Don't think I ever used it before that, nor
at all significantly after that ... mostly just a one-shot for
fairly large hierarchy of stuff, where (most) all access was only
via sftp - and not even (more general) ssh or the like.  So,
for that use case ... sshfs it was.  And essentially never before,
nor since.  Mostly a solution in search of a problem.  And almost
never encountered the problem for which it's the solution.

That's also why when I pulled up the info on it, man page, etc.,
I didn't even have it installed.  Extracted e.g. the man page info.,
from the Debian package (which I happened to have), but without having
the package installed (certainly at least not recently ... if ever,
at least for the host where I was looking at it).

> For the record, the last time I was obliged to use sshfs, on the VA
> Linux Systems corporate network, I found it to be painfully,
> unacceptably slow.

Yeah, it's kind'a sucky performance-wise, as I seem to recall.
Not only due to fuse, but notably a lot of filesystem-related system
calls really just can't be done over sftp, so stuff is emulated ...
more-or-less ... and sometimes that has to be a hard way around and
very, if not grossly, inefficient.  But, if time isn't a factor (hey,
machine time, not human time), it'll manage to get the deed done.
Saved me quite a bit 'o time of manual work ... and clock time ...
didn't need to sit and watch it - could certainly do other stuff
'till it was all done.  But I think once was quite sufficient.

> But anyway, as Michael pointed out, since you pointedly mounted the
> filesystem with just one UID/GID and omitted the flag that would have
> permitted others, you guaranteed this outcome.