On Sun, Dec 10, 2017 at 2:09 AM, Mike Jumper <[email protected]> wrote:
> On Thu, Dec 7, 2017 at 6:44 AM, Or Cohen <[email protected]> wrote: > > I was thinking of adding filesystem support to non-readonly non-owner users > > and I see that I need to change this in a few places (join handler, file > > request handlers, maybe more?). Is it easy as just making sure new users > > get a filesystem object and matching file download/upload requests, or > am I > > missing something? > > > > > That sounds about right. I would suggest tying filesystem access to > existing enable flags, like the existing "enable-drive" and "enable-sftp" > parameters, rather than combining everything into "read-only". I doubt that > assuming all non-readonly users should have access to available filesystems > is a safe assumption. > Yeah, you're right. I mentioned read-only because it can be expected that users with write (non-readonly) access also have filesystem access, i.e. it won't seem weird in that context. So I'm looking at the ssh protocol client and I checked if libssh2_sftp_* operations are thread-safe, and seems like they aren't. Regardless, I also see that file uploads actually have a listener for non-owners. I'm trying to think of a way to workaround the thread-safety issue, if it's indeed an issue. Since it's implementation dependent, maybe limit file operations on the protocol level? i.e. respond with "SFTP: Too many streams" or something.
