> I think the public free Sage notebook should be configured so that > the sageXX accounts cannot open sockets to the outside world. Period. > If I knew how to configure this in < 30 minutes, I would have done it already. > > Once we nail down a reasonably secure public sage notebook configuration, > I think we should configure a vmware image wiht it, and make that available > to people. >
Excellent. Prohibiting socket access will be easier to implement than building the compromise I proposed. > > > 2. Disallow killing processes by any sageXX account. This essentially > > > means limiting the interrupts that can be issued. > > I don't like this, since the net result will be lots and lots and lots > of zombie processes. Also, people killing other people's processes is > just slightly annoying vandalism and nothing else. > > Also, I think there should be a 1-1 mapping between sageXX accounts > and notebook user accounts. Whatever vmware image we configure, > it'll be that way. > Building a 1-1 mapping between usernames and Unix accounts will indeed eliminate the need to restrict the kill command. I believe it would be hugely beneficial to build an abstraction layer between the Sage user accounts and the underlying system accounts. For instance, suppose a cluster of Sage servers are deployed for use on campus. It would be useful to obtain the user's credentials from an LDAP server or some form of single sign-on service. I'm guessing people would find one or all of the following user abstraction modules useful: 1. Sage usernames, passwords, and meta-data stored in db backend. When accounts are accessed, they are temporary mapped to a system user based upon a predetermined server pool (similar to what is done now). 2. Sage usernames and passwords come from Unix backend. Extended meta- data for each user (such as Sage-related settings, etc) are stored in a db backend. 3. Sage usernames and passwords are authenticated based on LDAP information. Extended meta-data stored are stored in a db backend (note: at some point, a mapping must be made back to a Unix account. A new account could be generated based upon the LDAP information, but this is probably less than desirable for several reasons.). > Alternatively, we could have the sage notebook server just kill absolutely > all processes belonging to sageXX every so often. That's the price of > using a free resource. > True, but that seems a little unfriendly -- Brian --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
