On Nov 7, 2007 10:24 AM, Jochen Theodorou <[EMAIL PROTECTED]> wrote: > > Patrick Wright schrieb: > >> That changes very soon when running such an application with root > >> rights! It would be careless to not to address this. It might be enough > >> for Windows, but on a Unix like system it is really different. And I > >> don't know about you, but I do use scripting languages on the command > >> line more in a Unix-like environment. > > > > Yes, I know. I was trying to compromise and come closer to Charles' > > position on the topic :). > > > > It is a big drawback of the design. One reason it might be good to run > > it in a webapp container, where people already understand what the > > issues are, and are used to configuring it for secure access (in his > > defense, Marty pointed this problem out quite clearly). > > I was more thinking about a per user server. > > >> what rights is NG using when I write/read a file? If it is the rights > >> given by the server, because the server process is doing that, then it > >> can't never be run as root, unless you want grant any normal user access > >> to anything on the file system. It would be also interesting what NG > >> shows for properties set by the JVM like user.home > > > > It shouldn't be launched as root, that is true. > > > > It's a topic that needs to be addressed. > > even if it is not launched as root... I don't want another user to be > able to write into my home directory ;)
Clearly each launched nailgun should only work for the user who spawned it. A multi-user Nailgun seems like a dangerous Nailgun (heh). So, it sucks that Java does not support unix domain sockets (though I am not sure if Windows has equivalent concept). That seems like it would trivially fix the access issue. I wonder if JNA could give us enough functionality to hook this up? I personally, would not mind JNA as a dependency for this feature (JRuby already is using JNA). If we cannot use something like Unix Domain sockets then probably a randomly spawned password by client (which then spawns initial server instance) which then gets stored securely to a file in users home directory may do the trick. The successive calls would pass this secret as proof of ownership. The file that stores the password in would be chmod'd so other users cannot read it. This file could also store the pid of the server so we can make sure it did not die at some point. Combine that with Jochen's spawn on first command logic and there could be an ENV to main startup lang (jruby) script for people who don't mind having background server stick around for a while in case the person will do several invocations in a short period of time. I guess I am brainstorming, but I suspect we can add or layer something reasonable onto what exists now... -Tom -- Blog: http://www.bloglines.com/blog/ThomasEEnebo Email: [EMAIL PROTECTED] , [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
