On Thu, Dec 7, 2017 at 6:44 AM, Or Cohen <[email protected]> wrote: > Hi, > > I have a use-case where I need to enable other users to access the > filesystem object. Looking at the (server) code, I saw that it's not shared > with users that are not the owners and that it's intentional. > I also saw that it's consistent, e.g. not responding to file download > requests if the user is not the owner. > > Correct.
I'm wondering if this choice is due to some limitation (shared data between > threads, etc.) I'm not aware of, or some behavior that is chosen because > this is what the users expect. > > Only human limitations. ;) Implementing file transfer for only the owner simplified the initial release of screen sharing support. There is no technical reason why this can't be done, with the original intent being to provide flags allowing administrators to explicitly enable filesystem access for joining users via the parameters submitted when joining. 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. - Mike
