Начнем с того, что в elk-browser тоже не открывается (хотя его я внимательно не смотрел - может, там настройки)
Получается, что в имеющихся браузерах под МСВС нет встроенной поддержки JSON. Может быть попробовать выкрутиться задействовав функцию eval()? Но:
Техника использования eval() делает систему уязвимой, если источник используемых JSON-данных не является доверенным. В качестве таких данных может выступать вредоносный JavaScript код для атак класса Внедрение кода. С помощью данной уязвимости возможно осуществлять кражу данных, подделку аутентификации. Тем не менее, уязвимость можно устранить за счёт использования дополнительных средств проверки данных на корректность.
filatovka
А вообще без строки в fstab раздел всё равно монтируется при загрузке?
Похоже, либо монтирование сразу осуществляется с опциями по умолчанию (кто знает, что там ВНИИНС намутили...), либо что-то перемонтирует раздел уже в процессе.
В качестве последней попытки найти виновника: # grep -R hda5 /etc /var/log.
Возможный путь обхода проблемы: можно добавить в /etc/rc.local (перед exit, если есть) команду перемонтирования с нужными опциями: mount -o remount,gid=506,fmask=117,dmask=007 /dev/hda5.
Перехожу на мсвс (пробую "80001 12 изм 06" ядро 2.4.32, жду получения "80001 14 изм 06") с "зос оливия" (ядро 2.4.31) - т.е. системы почти одинаковые
Но замечаю ухудшение быстродействия на мсвс (железо все тоже самое), заметное на глаз - раза в 2
Например тест hdparm выдает по чтению из буфера на мсвс 160 Мб/с в то время как на оливии 410 Мбс (чтение с диска на обоих одинаково и составляет 5Мбс - так мало потому что это compact flash)
Причем X не установлены, работает "минимальное" окружение (самое тяжелое это cups)
С помощью strace посмотрел как например работает http://www.johnath.com/beep/:
мсвс http://pastebin.com/gE0m7iCv
оливия http://pastebin.com/fFDLxgei
Видно, что мсвс выполняет "лишние" действия - как их отключить ? (вопросы безопасности меня не интересуют, не надо их затрагивать)
Или любые другие мысли приветствуются по возвращению былого быстродействия на томже железе (могу сделать другие тесты если необходимо)
filatovka
А вообще без строки в fstab раздел всё равно монтируется при загрузке?
Похоже, либо монтирование сразу осуществляется с опциями по умолчанию (кто знает, что там ВНИИНС намутили...), либо что-то перемонтирует раздел уже в процессе.
В качестве последней попытки найти виновника: # grep -R hda5 /etc /var/log.
Возможный путь обхода проблемы: можно добавить в /etc/rc.local (перед exit, если есть) команду перемонтирования с нужными опциями: mount -o remount,gid=506,fmask=117,dmask=007 /dev/hda5.
ОК! Попробую ещё и этот вариант, а вообще у меня с самого начала было ощущение, что они малость перебдели с безопасностью. Хотя не их это вина.
Jun 10 16:50:20 host12 kernel: ppdev: user-space parallel port driver
Jun 10 16:50:21 host12 insmod: /lib/modules/2.4.32-vniins42/kernel/drivers/parport/parport_pc.o: init_module: Device or resource busy
Jun 10 16:50:21 host12 insmod: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters. You may find more information in syslog or the output from dmesg
Jun 10 16:50:21 host12 insmod: /lib/modules/2.4.32-vniins42/kernel/drivers/parport/parport_pc.o: insmod parport_lowlevel failed
Jun 10 16:50:21 host12 kernel: ppdev0: no associated port!
Jun 10 16:50:21 host12 insmod: /lib/modules/2.4.32-vniins42/kernel/drivers/parport/parport_pc.o: init_module: Device or resource busy
Jun 10 16:50:21 host12 insmod: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters. You may find more information in syslog or the output from dmesg
Jun 10 16:50:21 host12 insmod: /lib/modules/2.4.32-vniins42/kernel/drivers/parport/parport_pc.o: insmod parport_lowlevel failed
Jun 10 16:50:21 host12 kernel: lp: driver loaded but no devices found
filatovka
А вообще без строки в fstab раздел всё равно монтируется при загрузке?
Похоже, либо монтирование сразу осуществляется с опциями по умолчанию (кто знает, что там ВНИИНС намутили...), либо что-то перемонтирует раздел уже в процессе.
В качестве последней попытки найти виновника: # grep -R hda5 /etc /var/log.
Возможный путь обхода проблемы: можно добавить в /etc/rc.local (перед exit, если есть) команду перемонтирования с нужными опциями: mount -o remount,gid=506,fmask=117,dmask=007 /dev/hda5.
После удаления строки раздел перестал монтироваться. Корректного завершения указанной команды я так и не дождался, а полученный вывод в прилагаемом файле. Файла /etc/rc.local я не обнаружил, зато обнаружил файл /etc/rc.d/rc.local. Я его тоже прилагаю, может в нём что-нибудь прописать?
У вас нет необходимых прав для просмотра вложений в этом сообщении.
После удаления строки раздел перестал монтироваться.
Если хотите, можете провести ещё такой эксперимент: закомментируйте строку в fstab, поставив # в начале, перезагрузитесь, убедитесь, что раздел не смонтирован, раскомментируйте строку и сразу выполните # mount -a. Если после этого раздел смонтируется с нужными опциями, то покажите файлы /etc/rc.d/rc* (можете добавить суффикс .txt, чтобы можно было прикрепить).
и покажите те скрипты, которые будут указаны в самом начале каждой строки результата перед двоеточием.
Кстати, mount какой версии? Проверьте: mount --version, нет ли в данной версии какой-нибудь ошибки, связанной с наблюдаемым поведением?
Slackware64-current/Xfce/Xiaomi Mi Notebook Pro 15.6 | Arch Linux/Xfce/Lenovo G580
------------- Registered Linux User #557010
После удаления строки раздел перестал монтироваться.
Если хотите, можете провести ещё такой эксперимент: закомментируйте строку в fstab, поставив # в начале, перезагрузитесь, убедитесь, что раздел не смонтирован, раскомментируйте строку и сразу выполните # mount -a. Если после этого раздел смонтируется с нужными опциями, то покажите файлы /etc/rc.d/rc* (можете добавить суффикс .txt, чтобы можно было прикрепить).
Эксперимент закончился неудачей Видимо бесполезная затея. Проблема скорее всего в средстве защиты информации. Авторизация пользователя происходит не на локальной машине, а на сервере безопасности, который разрешает вход на локальную машину. Я не знаю как это объяснить, но видимо такой пользователь обладает несколько иными правами по отношению к внутрисистемным процессам и в этом всё дело. На всякий случай выкладываю файлы...
и покажите те скрипты, которые будут указаны в самом начале каждой строки результата перед двоеточием.
Кстати, mount какой версии? Проверьте: mount --version, нет ли в данной версии какой-нибудь ошибки, связанной с наблюдаемым поведением?
А это вывод команды grep.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
На всякий случай уточню: при отсутствующей записи в fstab раздел не был смонтирован после загрузки, а после её добавления (раскомментирования) и немедленного выполнения # mount -a смонтировался, но не с теми опциями, что в fstab? Тогда причина найдена: либо это ошибка в самой программе mount, либо проделки ВНИИНС. В обоих случаях лучше, наверное, сильно внутрь не лезть, а просто добавить команду перемонтирования, как я писал.
На всякий случай уточню: при отсутствующей записи в fstab раздел не был смонтирован после загрузки, а после её добавления (раскомментирования) и немедленного выполнения # mount -a смонтировался, но не с теми опциями, что в fstab? Тогда причина найдена: либо это ошибка в самой программе mount, либо проделки ВНИИНС. В обоих случаях лучше, наверное, сильно внутрь не лезть, а просто добавить команду перемонтирования, как я писал.
Да, именно так. Правда с какими именно опциями он был смонтирован неизвестно, скорее всего по-умолчанию, потому как искомый результат не получен. А в какое место файла добавить команду перемонтирования? Дело в том, что в своём rc.local я не нашел слово exit.
А в какое место файла добавить команду перемонтирования?
В конец.
ИМХО, пора заканчивать с этим. Внесение изменений в файл rc.local не возымело ровным счётом никакого эффекта. Спасибо за помощь и живейшее участие в решении данной проблемы Я вот каждый день на работе имею возможность сравнивать две операционки: МСВС и ASPLinux 11 и удивляюсь, как можно было из одного и того же продукта (ну практически одного и того же) сделать такие разные вещи!
Внесение изменений в файл rc.local не возымело ровным счётом никакого эффекта.
Всё же покажите строку, что вы добавили в данный файл.
Кроме того, наличие эффекта следует смотреть в выводе команды mount, а не как-то иначе.
Короче говоря, если при наличии строки в fstab и правильной команде перемонтирования раздел всё равно оказывается смонтирован с не теми опциями, то тогда, действительно, делать нечего. Если же раздел перемонтировался, то тут уже вопрос в подборе таких опций, что вас устроят. Это несложно.
Внесение изменений в файл rc.local не возымело ровным счётом никакого эффекта.
Всё же покажите строку, что вы добавили в данный файл.
Кроме того, наличие эффекта следует смотреть в выводе команды mount, а не как-то иначе.
Короче говоря, если при наличии строки в fstab и правильной команде перемонтирования раздел всё равно оказывается смонтирован с не теми опциями, то тогда, действительно, делать нечего. Если же раздел перемонтировался, то тут уже вопрос в подборе таких опций, что вас устроят. Это несложно.
Выкладываю вывод команды mount и файл rc.local. Судя по всему, команды монтирования выполняются правильно, однако пользователю всё равно запрещено копировать файлы на данный раздел.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
/dev/hda5 on /mnt/data type vfat (rw,gid=506,fmask=117,dmask=007,gid=506,fmask=117,dmask=007)
Ну вот, где-то выше была уже строка из вывода mount с данными параметрами (только не дублирующимися). ИМХО, можно команду перемонтирования из rc.local убрать, т.к. монтирование с опциями через fstab работает корректно. Но мы, видимо, друг друга не поняли, и в результате ушли в сторону. Когда я это реализовывал у себя, я создавал отдельную группу, в неё включал пользователей, которым нужен доступ на раздел, проблем не было. А у вас, как я понимаю, раздел монтируется как указано, но доступа у членов группы почему-то нет?
Slackware64-current/Xfce/Xiaomi Mi Notebook Pro 15.6 | Arch Linux/Xfce/Lenovo G580
------------- Registered Linux User #557010
/dev/hda5 on /mnt/data type vfat (rw,gid=506,fmask=117,dmask=007,gid=506,fmask=117,dmask=007)
Ну вот, где-то выше была уже строка из вывода mount с данными параметрами (только не дублирующимися). ИМХО, можно команду перемонтирования из rc.local убрать, т.к. монтирование с опциями через fstab работает корректно. Но мы, видимо, друг друга не поняли, и в результате ушли в сторону. Когда я это реализовывал у себя, я создавал отдельную группу, в неё включал пользователей, которым нужен доступ на раздел, проблем не было. А у вас, как я понимаю, раздел монтируется как указано, но доступа у членов группы почему-то нет?
Да, именно, так. Только разница в том, что я не создавал отдельную группу с новыми пользователями, так как вынужден работать именно под этим пользователем, изначально существующем в системе. Видимо в этой его изначальности и кроется проблема. Но создавать новую группу с новым пользователем мне не имеет смысла.
Вам советовали создать новую группу и включить в неё существующего пользователя.
Также можно разрешить доступ вообще всем пользователям, воспользовавшись моим советом.
filatovka, а права доступа на точку монтирования этой группе даны? У меня mnt/data принадлежал root:ntfs и был дан полный доступ на каталог владельцу и группе, остальным - нет доступа. То есть, попробуйте выполнить:
# umount /mnt/vfat
# chown -R root:vfat /mnt/vfat
# mount --verbose -a -t vfat /dev/hda5
Кроме того, я создавал только группу, потому что не счел ни одну группу подходящей из имеющихся в системе, и в неё добавлял существующего пользователя - себя (ну и рута). Новых пользователей создавать не нужно, повторяю, все пользователи, которым нужен доступ на fat-раздел, должны быть членами этой группы.
Slackware64-current/Xfce/Xiaomi Mi Notebook Pro 15.6 | Arch Linux/Xfce/Lenovo G580
------------- Registered Linux User #557010
filatovka, а права доступа на точку монтирования этой группе даны? У меня mnt/data принадлежал root:ntfs и был дан полный доступ на каталог владельцу и группе, остальным - нет доступа. То есть, попробуйте выполнить:
# umount /mnt/vfat
# chown -R root:vfat /mnt/vfat
# mount --verbose -a -t vfat /dev/hda5
Кроме того, я создавал только группу, потому что не счел ни одну группу подходящей из имеющихся в системе, и в неё добавлял существующего пользователя - себя (ну и рута). Новых пользователей создавать не нужно, повторяю, все пользователи, которым нужен доступ на fat-раздел, должны быть членами этой группы.
Всем большое спасибо за советы! К сожалению эксперименты пока придётся прекратить. Уезжаю в командировку, потом отпуск. Короче, до связи
а права доступа на точку монтирования этой группе даны? У меня mnt/data принадлежал root:ntfs и был дан полный доступ на каталог владельцу и группе, остальным - нет доступа.
Насколько я понимаю, это не должно влиять. При монтировании объект папки-точки монтирования заменяется (в памяти ядра) на корень монтируемой ФС. Именно поэтому нет доступа к данным, находящимся в папке, после монтирования.
Указывать раздел - избыточно, да и наверняка вызовет ошибку "лишний аргумент", но перепроверить сейчас не могу.
Сегодня ещё успел посмотреть. Оказывается я с самого начала создал специальную группу и включил admsec в эту группу, ту что gid=506, единственно, я не включил в эту группу рута. Сегодня я это сделал, но опять ничего не изменилось. Кстати я удалил строку о перемонтировании из файла rc.local, но в выводе команды mount осталась удвоенная информация после перезагрузки. Почему? Всё остальное смогу проверить теперь нескоро!
Вобщем выкладываю отчёт о проделанной работе!
Видимо бесполезная затея. Проблема скорее всего в средстве защиты информации. Авторизация пользователя происходит не на локальной машине, а на сервере безопасности, который разрешает вход на локальную машину. Я не знаю как это объяснить, но видимо такой пользователь обладает несколько иными правами по отношению к внутрисистемным процессам и в этом всё дело. На всякий случай выкладываю файлы...