On Wed, Jul 22, 2009 at 11:21 AM, nrbruin<nbr...@sfu.ca> wrote: > > I have wondered about Peter's problem as well. Particularly in larger > classes, one wouldn't necessarily trust all students to behave nicely. > In those cases, it would be nice to have a sage notebook that runs a > little more locked down. > > As a point of feedback that some of the sage advocates might care > about: > The security concerns have prevented me from asking the local > sysadmins to install a student-accessible notebook server. If we had > one, I would be more inclined to include some sage-based assignments > in courses (I have tried before, relying on the public servers - with > mixed results) > > A partial solution would be to have a "sage coursework appliance", > running as a virtual machine. In a virtual machine, there would be no > problem binding (local) unix UIDs to sage notebook server accounts. > Then the sage engine could be run setuid-ed to the corresponding user > id, thus shielding students more properly from each other. Plus, an > expert would only have to do all the setroot jailing etc. once, for > the benefit of everybody else. I wouldn't trust myself, or the average > sysadmin, with setting up a proper setroot jail. > > If there were an admin page where one can manage accounts in a big > table (class list upload?), it could be quite straightforward to set > up accounts for the course. > > In fact, there are universities that have a central authentication > service, such as http://www.jasig.org/cas. If sage's authentication > were to be made pluggable, plugging into services like that would be > not particularly difficult and means you don't have to do any password > management. There is a trusted third party that will vouch for the > user's identity. All you're left with is to decide if that user is > authorized to use the service. That means no handing out of login > details in class! It also means that students are using the service > with an account that is definitely trackable to them. That's a > deterrent to misbehaviour. > > Perhaps William feels inclined to consider these options when he > starts working on the notebook in September? He'll probably come up > with much better solutions.
Yep, that's exactly my plan. I think everybody agrees that a trivial-to-use implementation of the sort of backed infrastructure you describe above would vastly increase the potential deployability of Sage. Many thanks for clearly laying out what users need above. William > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---