On Thu, Oct 29, 2009 at 9:52 AM, William Stein <wst...@gmail.com> wrote: > On Thu, Oct 29, 2009 at 9:05 AM, Jason Grout > <jason-s...@creativetrax.com> wrote: >> >> David Guichard wrote: >>> Thanks Robert--works fine. >>> >>> I sort of answered my question about simultaneous connections: >>> apparently one account in the server pool can be used by two users--it >>> appears to just log in twice as that user. There must be a good reason >>> to have more users in the server pool, though, right? What is it? I >>> did notice that when I stopped the server one of the logins stayed >>> alive and I had to kill it manually. >>> >> >> >> The server pool is just a load-balancing and security thing. When a user >> starts up a Sage session, Sage selects on of the entries in the server >> pool (using random or round-robin load balancing, I think) and uses that >> to start the user's session. >> >> At least, that's how it was used to work. I don't know if the new >> notebook code changed things. > > This is all still true, and the relevant code hasn't changed at all. > >> In general, there is no connection between the number of notebook users >> and the number of server pool entries. The nice security thing about >> having lots of server-pool entries even when on the same server is that >> you can make each a separate unix account. Then simultaneous logins >> likely won't be running on the same unix account, and so can't mess with >> each other's files in a malicious (or nonmalicious) way. At least, I >> think permissions are set up so the workspace is not writeable by other >> people. > > This motivation has changed significantly. When the notebook server > evaluates an input cell, the following now happens: > > (1) The notebook server writes the code to be evaluated to > /tmp/randomstuff/code.py (or something like that). > (2) The worksheet process (which is being controlled over ssh) > changes its current directory to /tmp/randomstuff, which is world > writable. > (3) The code is run which produces output, including output to > stdout and the creation of files (e.g., images). > (4) The output is copied back to the private notebook server's > directory, which is *not* world writable. Unfortunately, some of this > directory is world-readable right now, only because of the DATA > directories. > (5) The tmp/randomstuff directory is deleted. > > As you can see, the vandal-style damage that a user can do is vastly > more limited now. It used to be the case that any user could delete > any files of any other user that happened to have been created by the > same worksheet process. Now, even if the server pool has only one > account, there is only a very tiny window of opportunity for the user > to do something malicious (i.e., right when another user is evaluating > some code, maybe the code.py file could be changed, or the output > files be deleted). Moreover, the worksheet process can be setup so > it only has write permissions on /tmp/ (i.e., don't give them a home > directory), and /tmp/ can be made a RAM disk. > > In the near future I'll also fully support the worksheet processes [...]
This design is now http://trac.sagemath.org/sage_trac/ticket/7350 William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
