On Jun 27, 1:57 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> I'm a little worried about creating new accounts for each user, just because > that means the Notebook server has to have the ability to create new accounts, > which is probably a pretty serious ability to have. But I suppose sudo could > give them just access to the adduser command and not much else. Actually, > I sort of like this idea. > > William I understand that the ideas you are developing here are highly appropriate for an open notebook and are probably applicable to VMware'd systems too. However, the typical potential user doesn't have admin access themselves. It will be hard enough to convince system administrators to install software that listens on an outside port, but if that software can ALSO make new user accounts, it will probably be impossible (and otherwise the sysadmin should be fired) Please keep in mind there are other usage scenarios as well: - sage runs on a private machine, with essentially only one authorised login (think laptop) - sage runs on a workstation, with one main user but multiple people authorized to login (standard networked workstation) - sage runs on a rack server; multiple people are allowed to login and regularly do - prof wants to use sage as a teaching tool and for students to do assignments. Students are not very trusted, but the prof administering the sage system probably only has limited authority on the machine it runs on. Scenarios 1 through 3 would not necessarily be chrooted, because people using the notebook would normally have shell access anyway. The notebook could just listen on a local port and people can connect via ssh tunnels. It might even be desirable that, after authentication, I can access my own homedir files (makes for easy attaching & editing of custom programs and allows me to communicate easily with normal - homedir centric software. On the other hand, sage su-ing to my uid would make me slightly uncomfortable (sage is too complicated a program to do such delicate things). Scenario 4 does need good lockdown and probably protection against vandalism. However, the prof may not have enough permissions to set up what you described before. In this scenario, the notebook would probably have to listen on an outward port. The only thing that makes it not quite a "public" notebook is that accounts are not freely given out. Incidentally, if the notebook connects via ssh to the sage sessions, there is no reason for them to live on the same computer either anymore! This opens the road of running a central notebook process, where all the members of the department can connect. From there, the sage processes are run on a collection of machines! This setup only needs that the system can trust that the relevant parts of the filesystem are network shared, or (for the read-only parts) exact copies on all machines involved. These conditions are normally easy to meet on departmental research networks. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
