особенности файловой системы UFS на Solaris
Недавно возникла у меня неординарная ситуация. Сайт располагался на Solaris 9 и была там слепая Sql-inj (под которую собственно и был написана предыдущая статья). Так как там была MySQL 3 ни о каких UNION и подзапросах речь не шла. Шелл тоже не заливался. Единственное, что я мог так это читать файл через LOAD_FILE.
Однако, была одна надежда – нужно было прочитать один скрипт, который располагался в поддомене основного, но путь к нему я не знал. Честно говоря, я на солярном сервере вообще плохо ориентировался.
Решение мне подсказал rat-energizer с rdot‘а.
решение
Читаем /etc/vfstab и видим там что-то типа
#device device mount FS fsck mount mount
#to mount to fsck point type pass at boot options
#
fd - /dev/fd fd - no -
/proc - /proc proc - no -
/dev/md/dsk/d2 - - swap - no -
/dev/md/dsk/drk /dev/md/rdsk/d1 / ufs 1 no logging
/dev/md/dsk/dw /dev/md/rdsk/d3 /www ufs 2 yes logging
/dev/md/dsk/dat /dev/md/rdsk/d4 /data ufs 2 yes logging
/dev/md/dsk/da /dev/md/rdsk/d5 /app ufs 2 yes logging
swap - /tmp tmpfs - yes--
Внимательно смотрим и если видим там UFS, то дело в шляпе.
Документации по этой теме я не нашел. Короче суть дела в том, что файловая система UFS, по крайней мере, в Solaris предоставляет возможность читать директории как файлы. Программно открыв директорию можно получить список содержащихся там файлов.
Эта директория-файл читается как бинарный файл, поэтому скрипт не должен останавливатся когда при чтении дойдет до символа с ASCII больше 127 или равному 0.
Для примера, если прочитать /etc, то в выходном файле будет что-то типа
...TIMEZONEautopushcfgadmclricroncron.ddcopydefaultdfsdhcpfffmthardformatfsfsck
и так далее...
Если вы будете использовать эту возможность, для считывания файла через MySQL через мой скрипт в прошлой статье, то там следует поменять условия проверки окончания файла, если ASCII-код символа равен 0 или больше 127.