Ed Schaum wrote:
I fixed my installation, but I'm not sure exactly how.
First, I backed everything up.
I then set the language variable in rlconfig (the SDBM_File thing),
previously it had been blank.
Based on your description, I think that was it. Your hosting provider
probably installed the Perl module GDBM_File without installing the GNU
gdbm library. That confused Ringlink, and setting
$rlmain::DBM_File = 'SDBM_File';
in rlconfig.pm takes care of it.
Then I recreated the language files again using langinstall.pl
My ring is working again, and my language file directory has some new
entries, each language now has 2 files, one with a .dir extension and
one with a .pag extension. Earlier today, my language file directory
had files like de, en, es, etc. with no extensions.
Yes, that's how the database files that are generated by SDBM_File are
named. If you like, you can try
$rlmain::DBM_File = 'DB_File';
in rlconfig.pm instead (and run langinstall.pl again). That would
probably result in one file per language without file extensions. (But
it doesn't really matter.)
I also changed the name of the directory leading to my data and the
associated cgi shebang at the top of each perl file. When the program
was bombing out, it was revealing the name of my "secret" directory.
Once I'm sure everything is working right, I'll move my data above my
web root so this won't be a problem in the future.
If you have a sensibly configured web server, it doesn't allow reading
of your cgi-bin files from the web anyway. Otherwise, moving /lib and
/data to a location outside your document root may be a good idea.
As regards revealing of paths: Full paths should only be shown when you
run admin.pl, which only you have access to. Error messages from the
other .pl files should _not_ reveal the full paths. Please let me know
if you have found otherwise.
Some would argue that such error messages should not be displayed on
screen at all in a production version of a CGI program. However, if they
weren't, it would be much more difficult to provide assistance when
people encounter difficulties. The majority of Ringlink users are not
used to parse the server's error log when something goes wrong, and many
don't even have access to it.
I'm still concerned about how this happened though, is there a
vulnerability in 3.1 that someone is exploiting to do this to ring
installations?
Not that I'm aware of.
Oh yeah, there's one other thing I did. I had messed around with the
PGetText.pm in the Locale directory under the secret directory. After
messing around with it, I wasn't sure if I put everything back the way
it was. Since I didn't have a backup of that file handy, I then
uploaded a copy of the PGetText.pm from v3.2.
It doesn't matter; that file is identical.
/ Gunnar