Проблема с именем пути к файлу, возможные поврежденные символы

Question

Perl и html, CGI на Linux. Проблема с именем пути к файлу, передаваемым в поле формы, в CGI на сервере. Проблема связана с файлом Linux, а не с ПК.

Я использую 2 программы, 1) программа, написанная лет назад, динамический html, сгенерированный в программе perl, и представленный пользователю как форма. Я изменил, вставив необходимый код, чтобы пользователь мог выбрать файл со своего ПК, который должен быть размещен на машине Linux.

Поскольку эта программа уже знает FilePath, необходимый на стороне Linux, я прохожу этот путь файл в скрытом поле формы, чтобы запрограммировать 2.

2) программа CGI на стороне Linux, чтобы работать, когда бланк (1).

Странный выпуск. Путь к файлу, который я передаю, имеет очень странную проблему. я могу извлечь его с помощью

my $filepath = $query->param("serverfpath"); 

выше делает заселить $ Filepath с тем, что выглядит точно правильный путь.
Но это терпит неудачу, и не так, что приводит меня к открытому блоку ошибок файла, но так, что вызов сценария CGI дает ошибку.

Однако, если я заполняю $ filepath ТОЧНО одной и той же строкой, используя жесткую кодировку, она работает, и мой файл успешно загружается.

Например:

$fpath1 = $query->param("serverfpath"); 
$fpath2 = "/opt/webhost/ims/DOCURVC/data" 

Сравнение $ fpath1 и $ fpath2 показывает, что они в точности равны. Проверка длины $ fpath1 и $ fpath2 показывает, что они имеют одинаковую длину.

Я пробовал много методов очистки данных в $ fpath1. Я chomp it. Я удаляю любые нестандартные символы.

$fpath1 =~ s/[^A-Za-z0-9\-\.\/]//g; 

и это:

my $safe_filepath_characters = "a-zA-Z0-9_.-/"; 
$fpath1 =~ s/[^$safe_filepath_characters]//g; 

Но независимо от того, что я делаю, используя $ fpath1 вызывает ошибку, используя $ fpath2 работы.

Что может быть неправильным с данными в $ fpath1, что приведет к его успешному сравнению с $ fpath2, но не будет равным, визуально выглядят ровно равными, показывают, что они имеют одинаковую длину, но не работают одинаково ?

Для открытого файла с открытым файлом.

$upload_dir = $fpath1 

причины полный провал CGI для загрузки, так как если он не может найти CGI (который я знаю, иногда вызывается синтаксической ошибки в сценарии CGI).

$uplaod_dir = $fpath2 

Я получаю успешный файл загрузить

$uplaod_dir = ""   

Вызов КГИ не подведет, он выполняет еще блок ниже, если, как и ожидалось.

здесь файл открыт блок:

if (open (UPLOADFILE, ">$upload_dir/$filename")) 
{ 
binmode UPLOADFILE; 

while (<$upload_filehandle>) 
{ 
print UPLOADFILE; 
} 

close UPLOADFILE; 
$msgstr="Done with Upload: upload_dir=$upload_dir filename=$filename"; 
} 
else 
{ 
$msgstr="ERROR opening for upload: upload_dir=$upload_dir filename=$filename"; 
} 

Какие тесты я должен выступать на $ fpath1, чтобы выяснить, почему он не работает так же, как ее жестко закодированы эквивалент $ fpath2

Я попробовал замену символов, один символ за раз, от $ fpath2 до $ fpath1. Даже делая это с одним символом, он вызвал ошибку $ fpath1 с той же ошибкой, что и $ fpath2, хотя персонаж выглядел точно так же.

Answer 1

Является ли ваш CGI, возможно, работает на Perl с -T (режимом порчи) переключателем (например, #!/usr/bin/perl -T)? Если это так, любое значение, исходящее из ненадежных источников (например, пользовательский ввод, URI и поля формы), не разрешается использовать в системных операциях, таких как open, до тех пор, пока оно не будет очищено с помощью захвата регулярных выражений. Обратите внимание, что использование s/// для его изменения на месте будет не не использовать значение.

$fpath1 =~ /^([A-Za-z0-9\-\.\/]*)$/; 
$fpath1 = $1; 
die "Illegal character in fpath1" unless defined $fpath1; 

должен работать, если taint-режим является вашей проблемой.

Answer 2

Но это не так, и это не то, что приводит меня к открытому блоку ошибок файла, но так, что вызов сценария CGI дает ошибку.

Преждевременный конец заголовков скриптов? Попробуйте запустить CGI из командной строки:

perl your_upload_script.cgi serverfpath=/opt/webhost/ims/DOCURVC/data