Re: [gbd-dev] Multi-user Debugging on Linux Server
Status: Beta
Brought to you by:
mccabe
From: Aaron M. <wmc...@ho...> - 2005-06-25 17:21:48
|
Hello, You're right Linus. My change assumed that the debugger would always be invoked via StartSession.php. I'd be happy to look into it and make the necessary updates to Gubed.php, etc. Here's my two cents on the multi-user stuff. I think allowing the HTTP request to contain the client and port could be a major security risk. This risk could of course be addressed by sysadmins with .htaccess files, etc. but do we really want Gubed to be such a security vulnerability upon installation to a public server? I understand that the presence of the devel directory is a security risk today, but otherwise, Gubed will only send server content to the client that is specified in the localsettings file (correct me if I'm wrong here). Requiring the client and port to be in the localsettings file then means that the user must be able to specify the localsettings file that should be used for the current debug session. I agree that it is kind of a pain to specify a full file path and to create a localsettings file instance for every debug session, but I'm just not very comfortable with the alternative. If it is decided to allow the user to specify the client and port in the request, then I think I like the idea of specifying the user in the request and then looking for say a .gubed file (renamed version of localsettings) in the user's home directory. A problem I see with grabbing the user from the URL (~user) is that scripts within the user's directory could only be debugged by this user. This would not be ideal in a situation where trusted developers may need to help debug each other's scripts. The use of .htaccess files, possibly in combination with php safe mode, would be my preference for preventing users from debugging each other's scripts in an untrusted multi-user environment. Thanks, Aaron McDonald ---------------------------------------------------------------------------------------------------------------------------- Hello! A good idea about using ssh instead of the proxy, that should work much more transparent! Since ssh exists for a number of platforms, I think this means that we can completely disregard the proxy in this discussion since ssh's forwarding makes it look like a local network to Gubed. (in any case, also the proxy should make it look like a local network to Gubed) Adding a port as a request variable to StartSession shouldn't be too much of a problem, Aaron has already added the possibility to specify different localsetting files. The problem with Aarons implementation, that I realized this morning, is that it only works when using StartSession (correct me if I'm wrong Aa). Sometimes it's not possible to use StartSession for Gubed (for example when javascripts are used to execute php scripts), instead you have to manually include Gubed.php in your script. Some of Aarons changes has to be moved to other files to make this possible. Before we proceed with further changes though, I'd like to discuss the optimal way of specifying different users. * I'm toying with the idea of using a localsettingsfile from the users homedirectory automatically if it exists. So if Gubed sees a ~ in the request (or is this too apache-ish?), it would figure out the user home dir from the request and take localsettings.php from there. This would make it easy for the user to alter his/her settings and nothing would need to be specified on the request (exept the script). * Second way of specifying what settings you want to use is by specifying a certain username on the request. Then gubed would use localsettings_{$gbdUser}.php for settings and startsessionhistory_{$gbdUser}.txt as history file. The reason I'd like to have this is because I think it's easier to remember and specify a single name like 'linus' rather than a complete path to a file. (is this a problem if the user uses different computers different days? I think not) * Third way would be to specify a localsettings filename in the request like in Aarons patch. * If no user or settingsfile was specified, the default (like now) is used. (Or should it first look for a file that's localsettings_{REMOTE_ADDR}.php to see if there is a special one for that host?) * Optionally you can override the host or port in whatever settingsfile was chosen by specifying host and port on in the request. This would only be needed if you were debugging several scripts simultaneously. Any comments on this? Is the above giving too many options and just making it harder rather than easier to know what to do? What about security - if you can specify debug host/port on the request will it be easier for a stranger to gain debug access to scripts? Or is this not Gubed's problem, but one of the sysadmin who installs Gubed on a public server? /Linus |