Re: Проблема с правами доступа в Debian
19 марта 2018 г., 13:56 пользователь Galina Anikina
<merilaga@yandex.ru> написал:
> Да пользователи там и там были созданы в разное время-
> то есть наоборот
> На одном разделе допустим ввели 1-го и 2-го пользователя, при этом 1-ый
> пользователь получил (на мой взгляд) излишние права - как первый и
> поэтому на второй системе они были созданы наоборот.
> НО ! Как может производиться монтирование только по UID? Не учитывая
> имени пользователя?
Потому что подключение диска от другой системы - нештатная ситуация.
Если хотите, чтоб при подобном не было доступа к чужим данным - шифруйте.
А для локального /home - достаточно проверять uid.
Тем более, в файловой системе нет такого атрибута, как имя пользователя.
> Получается, что производится усечённая проверка
> прав пользователей на соседнем разделе только по UID. Сейчас подумаю,
> какой аналог привести, чтобы было понятно. Например - в юридическом
> смысле не будет являться полной идентификация человека только по
> отпечатку пальца, без паспорта (в нашей стране) или другого документа
> (в другой стране) и личного физически присутствия (как в банке при
> получении кредита записывают на видео). То есть это не совсем
> полноценная идентификация (с возможностью компроментаций).
> Так и в этом случае - подмонтированная система монтируется получается
> кое-как, с минимальной проверкой прав.
Не надо ложных юридических аналогий.
Вы создали ситуацию, нештатную для системы и хотите странного.
Здесь, скорее, стоит посмотреть в сторону совместимости при переливании крови.
> Насчёт поменять UID - спасибо сделаю, но всё же хотелось бы, чтобы
> проверялось не только по UID а и по имени пользователю и если они не
> совпадают, то программа должна уведомить root-а в момент монтирования и
> возможно предложить какое-то решение.
Не будет такого решения без полного переписывания, как минимум, всей
libc + новой фс, где имя пользователя таки является одним из атрибутов
файла.
> Это был бы логичный разумный вариант разрешения данного вопроса.
Невозможный вариант пока что.
Придётся переписать 1) фс (хранение как uid, так и username), 2) libc
(вызов stat и ему подобные), 3) софт, работающий с атрибутами файлов
(весь!)
+ потеряется совместимость с POSIX, вероятно.
Получится не linux.
> Кстати вот ещё пример на тему - обоснования зачем это надо-
> Представьте школу и учитель информатики установил на один компьютер в
> сети систему и ввёл пользователей 1 и 2. (Ну или если школа или кружок
> маленькие - то установил на разных разделах одного компьютера разные
> системы, чтобы продемонстрировать детям разные операционные системы)
> Далее через некоторое время или учитель сменился или заболел и его
> подменяли (причин может быть много) - другой человек установил систему
> на другом компьютере - в этой же сети ввёл двух пользователей, но в
> обратном порядке. Один ученик (любопытный) примонтирует соседний раздел
> и попадёт к примеру в каталог учителя...
Здесь проблема не в том, что есть доступ в каталог учителя, а в том,
что есть NNN разделов, когда должен быть один.
Если может быть много пользователей на множестве компов, то проще
завести какой-нибудь LDAP и хранить пользователей в нём, чем так
извращаться.
Заодно можно будет вынести /home на nfs
Если правильно помню, когда-то школьный или околошкольный альтлинукс
делал такое штатным образом...
> Или ещё пример - на домашнем компьютере установлены две системы -для
> работы и для домашних развлечений, и там введены два пользователя -
> муж-жена, брат-сестра, два соседа по съёмной квартире и тд, Я думаю
> смысл понятен.
Аналогично. Если есть доступ к железу - нет смысла возиться с
правильными uid, когда сосед может просто загрузиться к какого-нибудь
кноппикса и прочитать вообще всё.
Вообще, основная проблема тут - не в том, что в фс что-то не хранится,
а в организации работы с данными.
--
Stanislav
Reply to: