Thread: 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 |
From: Brett S. <tec...@se...> - 2005-06-25 23:13:09
|
After reading both posts, I can see the difficulities of both security and implementation. I agree that what ever is done, must be secure or gubed will not be used. As a thought, we could optionally restrict the DebugServer to 'localhost'. When this restriction is in place, any individuals needing to debug need to either log on and start the debugger locally or run secure shell as previously described to create a local port to bring the session back to their local system. This would give the local system administrator strict control over who could debug, but not what they could debug. On this second point, seems to me that StartSession.php (soft-link or real) must exist at or below the directory to be debugged, while this doesn't control who can debug what, it does limit what can be debugged control by existing access to the host's directory structure. I favor allowing specification of ports on the url for maximum flexibility, presuming the security issue is resolved. Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Linus M. <Li...@mc...> - 2005-06-26 06:28:50
|
Perhaps then we should have two setting files, global and user. In the global setting file you can set defaults and here we could also have settings like: * allow remote debuggers - ie non localhosts * show developer help - which enables/disables the debug subdir * allow port/host on request * Also default host and port could be specified here. In the user settings files (which probably shouldnt be php files then, but normal config files) only host and port can be overridden. Is this a good compromise? /linus On Sunday 26 June 2005 01.12, Brett Serkez wrote: > After reading both posts, I can see the difficulities of both security > and implementation. > > I agree that what ever is done, must be secure or gubed will not be > used. > > As a thought, we could optionally restrict the DebugServer to > 'localhost'. When this restriction is in place, any individuals needing > to debug need to either log on and start the debugger locally or run > secure shell as previously described to create a local port to bring the > session back to their local system. This would give the local system > administrator strict control over who could debug, but not what they > could debug. > > On this second point, seems to me that StartSession.php (soft-link or > real) must exist at or below the directory to be debugged, while this > doesn't control who can debug what, it does limit what can be debugged > control by existing access to the host's directory structure. > > I favor allowing specification of ports on the url for maximum > flexibility, presuming the security issue is resolved. > > Brett > > ------------------------------------- > Brett C. Serkez, Technical Trainer > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Gubed-devel mailing list > Gub...@li... > https://lists.sourceforge.net/lists/listinfo/gubed-devel |
From: Aaron M. <wmc...@ho...> - 2005-06-26 15:15:51
|
Sounds pretty good to me. Any insecure functionality could be disabled by default and hopefully only enabled in a secure environment. The documentation could warn the user of the risks of enabling the functionality and advise what security measures should be in place. Will we be getting rid of the localsettings file parameter? One of the things I like about it is that it allows a user to have simultaneous debug sessions and allows multiple projects to be debugged at the same time but independently. I could go either way on this. Will "user" be a request parameter so that Gubed will know to read a user specific settings file? The user specific settings file should maybe include all the content of the current localsettings file so that a user could also use their own cache and do-not-debug list (and history file if it gets moved into localsettings). Thanks, Aaron McDonald --------------------------------------------------------------------------------------------------------------- Perhaps then we should have two setting files, global and user. In the global setting file you can set defaults and here we could also have settings like: * allow remote debuggers - ie non localhosts * show developer help - which enables/disables the debug subdir * allow port/host on request * Also default host and port could be specified here. In the user settings files (which probably shouldnt be php files then, but normal config files) only host and port can be overridden. Is this a good compromise? /linus On Sunday 26 June 2005 01.12, Brett Serkez wrote: >After reading both posts, I can see the difficulities of both security >and implementation. > >I agree that what ever is done, must be secure or gubed will not be >used. > >As a thought, we could optionally restrict the DebugServer to >'localhost'. When this restriction is in place, any individuals needing >to debug need to either log on and start the debugger locally or run >secure shell as previously described to create a local port to bring the >session back to their local system. This would give the local system >administrator strict control over who could debug, but not what they >could debug. > >On this second point, seems to me that StartSession.php (soft-link or >real) must exist at or below the directory to be debugged, while this >doesn't control who can debug what, it does limit what can be debugged >control by existing access to the host's directory structure. > >I favor allowing specification of ports on the url for maximum >flexibility, presuming the security issue is resolved. > >Brett > >------------------------------------- >Brett C. Serkez, Technical Trainer > |
From: Brett S. <tec...@se...> - 2005-06-26 15:49:04
|
> Sounds pretty good to me. Any insecure functionality could be disabled by > default and hopefully only enabled in a secure environment. The > documentation could warn the user of the risks of enabling the > functionality and advise what security measures should be in place. Agreed. Presumably there will also be warning comments in the configuration file? > Will we be getting rid of the localsettings file parameter? One of the > things I like about it is that it allows a user to have simultaneous > debug sessions and allows multiple projects to be debugged at the same > time but independently. I could go either way on this. I would advocate keeping the localsettings file parameter. I would still advocate for optionally allowing the DebugPort to be specified on the url for maximum flexibility. If the default will be to only allow connections to the local host, then in order for this to be exploited, the user would have to have a away to establish the socket on the local system. In the case of multiple debug sessions, without specifying the DebugPort on the URL, the localsettings file would need to be edited or copied. Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Brett S. <tec...@se...> - 2005-06-26 17:28:43
|
In order to support previous and current versions of our project, I am attempting to run Gubed under Windows/IIS. So far this has been an exercise in frustration, I'm wondering if it has ever been run under IIS? Looks like StartSession.php is hopelessly confused about directories. Gubed looks like it off by one directory, with a bit of manual overriding I can coax it to find the target php file, but then it is confused about finding its own files and I have yet to see the target php file in the debugger. I see the call to apache_lookup_uri() which I believe is compensating for this confusion when run under Apache. It looks like the reason why the soft-link works under Linux is that it allows the target php file to be found with a relative path but also the underlying operating system understands the files true location and allows the gubed helper scripts to be located. Before I continue, I was hoping there was some sage advise, that I missed something fundamental. I was also wondering how to debug Gubed itself? Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Linus M. <Li...@mc...> - 2005-06-26 18:47:42
|
On Sunday 26 June 2005 19.28, Brett Serkez wrote: > In order to support previous and current versions of our project, I am > attempting to run Gubed under Windows/IIS. So far this has been an > exercise in frustration, I'm wondering if it has ever been run under > IIS? I have run it on windows 2000 with IIS at one point, but lately i've only used apache when testing windows compatibility (since i don't have access to iis at home) > Looks like StartSession.php is hopelessly confused about directories. > Gubed looks like it off by one directory, with a bit of manual > overriding I can coax it to find the target php file, but then it is > confused about finding its own files and I have yet to see the target > php file in the debugger. I see the call to apache_lookup_uri() which I Are you using CVS or 0.2.0? There was a bug reported recently that's fixed in CVS where I had been using the wrong directory separator when setting the path. See: <http://cvs.sourceforge.net/viewcvs.py/gubed/Gubed/ServerScripts/Gubed.php?r1=1.6&r2=1.7> <http://cvs.sourceforge.net/viewcvs.py/gubed/Gubed/ServerScripts/GubedFunctions.php?r1=1.13&r2=1.14> (at the bottom) <http://cvs.sourceforge.net/viewcvs.py/gubed/Gubed/ServerScripts/GubedGlobals.php?r1=1.7&r2=1.8> I'm not sure it's a solution to your problem, but worth testing. Also, have you used slash replacement in the pathmapper dialog? The apache_lookup_uri was added to support apache aliases, it shouldn't be required in other cases but ofcourse, there might be sideeffects that im not aware of. > believe is compensating for this confusion when run under Apache. > > It looks like the reason why the soft-link works under Linux is that it > allows the target php file to be found with a relative path but also the > underlying operating system understands the files true location and > allows the gubed helper scripts to be located. Yes. But StartSession and the scripts debugged shouldnt need to be in the same directory. Do you have a similar setup with using developers home directories on windows? > Before I continue, I was hoping there was some sage advise, that I > missed something fundamental. > I was also wondering how to debug Gubed > itself? Now, this is tricky ;) I've never used Gubed to debug Gubed, I guess in theory it might be possible, but I'm not sure I want to try - it would get complex. You might be able to do it with another debugger like xdebug, but i havent tried this neither. So far, I've survived on echo's, die's and things like: gbdSendCommand("status", Array('message' => 'Shouldn\'t be here: %1%, %2%', 'args' => 2, 'arg1' => $gbdScriptname, 'arg2' => $gbdLine)); Also, when debugging a script, you can watch gubeds internal variables by watching $GLOBALS['gbd'] /Linus > > Brett > > > ------------------------------------- > Brett C. Serkez, Technical Trainer > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Gubed-devel mailing list > Gub...@li... > https://lists.sourceforge.net/lists/listinfo/gubed-devel |
From: Brett S. <tec...@se...> - 2005-06-26 19:28:55
|
> > Looks like StartSession.php is hopelessly confused about directories. > > Gubed looks like it off by one directory, with a bit of manual > > overriding I can coax it to find the target php file, but then it is > > confused about finding its own files and I have yet to see the target > > php file in the debugger. I see the call to apache_lookup_uri() which I > > Are you using CVS or 0.2.0? I've used both with identical results. Seems to be more an issue with an extra leading directory. > Also, have you used slash replacement in the pathmapper dialog? Not sure what this is, but I don't think the issue is related to slashes, see previous comment. > > It looks like the reason why the soft-link works under Linux is that it > > allows the target php file to be found with a relative path but also the > > underlying operating system understands the files true location and > > allows the gubed helper scripts to be located. > > Yes. But StartSession and the scripts debugged shouldnt need to be in the > same directory. Do you have a similar setup with using developers home > directories on windows? Yes, actually the Windows server is running off a Samba exported home directory so that both servers are working off the identical directory structure. Curious, I tried adding the Gubed ServerScripts directory to the php include path with no effect. I also noticed that the history file is being created in the directory of the scripts being debugged. Part of the issues is that if you run StartSession.php out of the ServerScripts directory, it doesn't understand ~user/directory/script.php. This is why I ended up with the softlink in the target directory. Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Brett S. <tec...@se...> - 2005-06-26 20:11:05
|
As a work around, I've attempted to use Apache vs. IIS on Windows for debugging, which should be close enough in most cases. I worked strictly with the latest CVS. I placed the ServerScripts directory in the web server root and was not able to run the test bench scripts via StartSession.php (via the supplied hyper-links). The first issue is that StartSession.php seems to want to prepend all scripts with 'c:\'. I found this also caused issues when trying to run out of user's public_html directories, see below. I add a line after line 38 of StartSession.php: $gbdBase = substr( ... ); // Existing line 38 $gbdBase = ''; // Force to null to inhibit prepending c:\ With this in place, I still had errors. If I changed the prefix: /php to GubedTest (i.e, changed /php/tests/... to GubedTest/tests...) All seemed to work. I'm presuming this is a simple change to the hyperlinks. I then moved on to replicating the Linux home public_html environment. Since Windows doesn't have soft-links, I had to copy StartSession.php into the desired directory and then fully qualify the path to Gubed includes. I attempted to update the php include path which didn't work, even to the extent of seeing the correct directory in the error message. I modified the require_once and include near the bottom of StartSession.php like so: require_once('C:\Program Files\Apache Group\Apache2\htdocs\ServerScripts\GubedFunctions.php'); include('C:\Program Files\Apache Group\Apache2\htdocs\ServerScripts\Gubed.php'); So far this environment *seems* to work as well at the Linux environment. Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Linus M. <Li...@mc...> - 2005-10-08 15:49:52
|
On Sunday 26 June 2005 22.11, Brett Serkez wrote: > I then moved on to replicating the Linux home public_html environment. > Since Windows doesn't have soft-links, I had to copy StartSession.php > into the desired directory and then fully qualify the path to Gubed > includes. I attempted to update the php include path which didn't work, > even to the extent of seeing the correct directory in the error message. > I modified the require_once and include near the bottom of > StartSession.php like so: > > require_once('C:\Program Files\Apache > Group\Apache2\htdocs\ServerScripts\GubedFunctions.php'); > > include('C:\Program Files\Apache > Group\Apache2\htdocs\ServerScripts\Gubed.php'); > > So far this environment *seems* to work as well at the Linux > environment. To this, I'd suggest an alternative method: In the user's home dir, put a php file that looks like this: <?php require_once('C:\Program Files\Apache Group\Apache2\htdocs\Gubed\StartSession.php'); ?> Pros: * You don't need full copies of StartSession.php with altered paths * The user cant change port etc by altering their StartSession file On the other hand; you can use the global StartSession to debug user's script, why do you need a copy in each user's home dir? /Lnus > Brett > ------------------------------------- > Brett C. Serkez, Technical Trainer > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Gubed-devel mailing list > Gub...@li... > https://lists.sourceforge.net/lists/listinfo/gubed-devel |
From: Linus M. <Li...@mc...> - 2005-10-08 15:52:27
|
On Sunday 26 June 2005 22.11, Brett Serkez wrote: > The first issue is that StartSession.php seems to want to prepend all > scripts with 'c:\'. I found this also caused issues when trying to run > out of user's public_html directories, see below. I add a line after > line 38 of StartSession.php: I'm unable to replicate this error with current CVS version. Do you still have this problem? /Linus |