AO
Угу, уря-уря! И спасибо
Size: a a a
2020 September 14
g
А сервер хранилищ под линукс же есть, да?
вроде давно
g
g
John Doe
Так у меня нет лекарства. Я для себя интересуюсь - ну т.е. типа зачем / когда можно хотеть сервер хранилища.
встречался только с политическими причинами в корп, где СБ не любит шары с полными правами, а вот если есть сервис - они не против
AO
gosn1ck
встречался только с политическими причинами в корп, где СБ не любит шары с полными правами, а вот если есть сервис - они не против
Только с политическими?
AO
А если я зайду и нечаянно дропну к херам эту шару с полными правами и всеми наработками?
g
не велика потеря, конфа на проде не сильно устарела, а все что до прода не доехало можно собрать по базам разработчиков
AK
Всем привет! Подскажите, видел, в 8.3.17 реализована возможность определения ip адреса компьютера, который начал сеанс с иб. По умолчанию в журнал регистрации или в технологический журнал пишется в 8.3.17 ip адрес?
JD
А шару ограничить по процессам ОС, имеющим туда доступ, нельзя? Туда же только пофигуратор (толстый клиент с ключом дезигнер) стучаться так-то должен.
ага.. каждый клиент же докаладывает серверу о том, что за приложение сейчас ломится в сеть
AK
ага.. каждый клиент же докаладывает серверу о том, что за приложение сейчас ломится в сеть
Дело в том что до 8.3.17 писалось только имя компьютера
JD
ага.. каждый клиент же докаладывает серверу о том, что за приложение сейчас ломится в сеть
Думаю, на клиенте перехватывать тср-трафик по порту шар и получить инфу по процессу ОС не проблема.
Но это не централизованно и поэтому ненадежно, да.
Но это не централизованно и поэтому ненадежно, да.
Логика у вас конечно классная. На клиенте конечно можно узнать, кто в шару ломится. Но с чего вдруг файл серверу это знать? Можно предположить, что по каким-то причинам это могли заложить в SMB протокол. Но выглядит глупо и нелогично.
AK
John Doe
Думаю, на клиенте перехватывать тср-трафик по порту шар и получить инфу по процессу ОС не проблема.
Но это не централизованно и поэтому ненадежно, да.
Но это не централизованно и поэтому ненадежно, да.
Спасибо, думал может у кого 8.3.17 стоит, сразу и посмотрят, скажут)
JD
Логика у вас конечно классная. На клиенте конечно можно узнать, кто в шару ломится. Но с чего вдруг файл серверу это знать? Можно предположить, что по каким-то причинам это могли заложить в SMB протокол. Но выглядит глупо и нелогично.
Ну тогда и ограничивать шару сервером хранилища от риска внезапного удаления тоже не дает никаких гарантий: никто разрабу не мешает захватить и дропнуть хранилище и через сервер хранилища
KK
Alex Kulikov
Всем привет! Подскажите, видел, в 8.3.17 реализована возможность определения ip адреса компьютера, который начал сеанс с иб. По умолчанию в журнал регистрации или в технологический журнал пишется в 8.3.17 ip адрес?
Не пишется. Просто добавили возможность из некоторых объектов такую информацию тягать.
AK
Не пишется. Просто добавили возможность из некоторых объектов такую информацию тягать.
Спасибо!
John Doe
Ну тогда и ограничивать шару сервером хранилища от риска внезапного удаления тоже не дает никаких гарантий: никто разрабу не мешает захватить и дропнуть хранилище и через сервер хранилища
вот тут как раз мешает контроль доступа на базе тех данных, которые заложены в протокол работы с хранилищем, в отличие от SMB. Думаю разница понятна?
JD
вот тут как раз мешает контроль доступа на базе тех данных, которые заложены в протокол работы с хранилищем, в отличие от SMB. Думаю разница понятна?
На шару доступ тоже можно определенным пользователям ОС только выдать. Чем это отличаться будет от выдачи доступа к самому хранилищу (с точки зрения возможности убить хранилище)?
атомарность разная. На уровне хранилища можно сказать, какие операции можно делать. На уровне шары - вы должны дать полный доступ к файлу, если планируется хоть как-то работать с хранилищем кроме чтения.