Re: [gbd-dev] Multi-user Debugging on Linux Server

[Aaron M. <wmc...@ho...>]

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