Проблема с правами доступа в Debian

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Проблема с правами доступа в Debian

Galina Anikina
Кто поможет составить bug-рапорт на английском о "Проблеме с правами
доступа в Debian"? (или сам составит, а меня только упомянет? - то есть
на правах соавторства)

Я бы её отнесла к очень серьёзной проблеме!


Это продолжается уже несколько лет! Ранее когда-то такого не было -
было полное совпадение имён и соответственно разрешалось смотреть
только тот каталог, у которого совпадают пользователи - хотя и это -
грубое нарушение безопасности! Ведь к пример если есть человек с
фамилией Сидоров, то это не значит, что ему разрешено открывать двери
квартир других Сидоровых, где бы они не жили - в Москве, Омске и тд!
Или другой пример - если ключ от вашей квартиру подходит к чужой
квартире - это ещё не значит что вы имеете право войти в неё! :-)))


Ранее "было полное совпадение имён и соответственно разрешалось
смотреть только тот каталог, у которого совпадают пользователи" - не
могу сказать в какой операционной системе Linux, но было всё нормально
- так как пробовала -ставила разные - начиная от Slackware и тд.

Возможно это проблема не Debian, а самой программы, которая занимается
распределением прав доступа или устанавливает права доступа на
примонтированных разделах. Поскольку я не программист по Linux мне
сложно сказать - где происходит неувязка. Но её необходимо устранить -
это однозначно. Тем более в таком уважаемом дистибутиве, как Debian!


Суть в следующем:


нахожусь пользователем rimma на sda5 с установленной системой
Debian_Buster/sid__Unstable

примонтировала sda3 с Debian Stable 9_4 - чтобы wallpappers перебросить
с sda3 на sda5





И получается абсурд
я могу посмотреть (полазить в нём) каталог не такого же пользователя
(если он совпал по имени - например rimma), а чужого - другого
пользователя (например tobik-а)!
К примеру я сейчас rimma и нахожусь на sda5, примонтировала sda3, далее
смотрю тот соседний раздел - home
и вижу что всё перепутано с правами!
 


Вот в
xfce4-terminal 0.8.7.1



mount /dev/sda3 /mnt


rimma@tamrik:~$ ls -All /mnt/home/
итого 32
drwx------ 50 tobik tobik 24576 мар 18 13:24 rimma
drwx------ 15 rimma  rimma   4096 мар 15 16:21 tobik
drwxr-xr-x  5 tobik tobik  4096 мар 15 17:10 y_walpappers



rimma@tamrik:~$ ls -All /mnt/home/rimma/
ls: невозможно открыть каталог '/mnt/home/rimma/': Отказано в доступе
(хотя на sda5 я сейчас пользователь rimma)




rimma@tamrik:~$ ls -All /mnt/home/tobik/
итого 100
-rw------- 1 rimma rimma     6 мар 15 16:21  .bash_history
......................

rimma@tamrik:~$

Ха а "чужого" - tobik-а разрешает просмотреть!

То же в
Thunar 1.6.14


Изнутри  Debian Stable 9_4 та же история (то есть если я нахожусь на
sda3 - Debian 9.4 Stable) - если оттуда примонтирую раздел sda5 с
Debian buster/sid Unstable.



 
Хотела написать об этой проблеме ещё пару лет назад, но поскольку надо
было писать на английском ....
Короче подумала, что кто-то заметит и напишет. Вот прошло время и "воз
и ныне там"!

Возможно этот баг уже зарегистирован, не смотрела, там сложно читать
:-((
Galina

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Grigory Fateyev-2
Это не проблема, а фича! Тут не в имени дело, а в UID. Посмотрите вывод id, по умолчанию в Debian, при установке, создаётся первый юзер с UID 1000. Похоже эти юзеры были созданны первыми при инсталяции системы и соответственно юзеры rimma и tobik имеют одинаковый UID.

19 марта 2018 г., 7:43 пользователь Galina Anikina <[hidden email]> написал:
Кто поможет составить bug-рапорт на английском о "Проблеме с правами
доступа в Debian"? (или сам составит, а меня только упомянет? - то есть
на правах соавторства)

Я бы её отнесла к очень серьёзной проблеме!


Это продолжается уже несколько лет! Ранее когда-то такого не было -
было полное совпадение имён и соответственно разрешалось смотреть
только тот каталог, у которого совпадают пользователи - хотя и это -
грубое нарушение безопасности! Ведь к пример если есть человек с
фамилией Сидоров, то это не значит, что ему разрешено открывать двери
квартир других Сидоровых, где бы они не жили - в Москве, Омске и тд!
Или другой пример - если ключ от вашей квартиру подходит к чужой
квартире - это ещё не значит что вы имеете право войти в неё! :-)))


Ранее "было полное совпадение имён и соответственно разрешалось
смотреть только тот каталог, у которого совпадают пользователи" - не
могу сказать в какой операционной системе Linux, но было всё нормально
- так как пробовала -ставила разные - начиная от Slackware и тд.

Возможно это проблема не Debian, а самой программы, которая занимается
распределением прав доступа или устанавливает права доступа на
примонтированных разделах. Поскольку я не программист по Linux мне
сложно сказать - где происходит неувязка. Но её необходимо устранить -
это однозначно. Тем более в таком уважаемом дистибутиве, как Debian!


Суть в следующем:


нахожусь пользователем rimma на sda5 с установленной системой
Debian_Buster/sid__Unstable

примонтировала sda3 с Debian Stable 9_4 - чтобы wallpappers перебросить
с sda3 на sda5





И получается абсурд
я могу посмотреть (полазить в нём) каталог не такого же пользователя
(если он совпал по имени - например rimma), а чужого - другого
пользователя (например tobik-а)!
К примеру я сейчас rimma и нахожусь на sda5, примонтировала sda3, далее
смотрю тот соседний раздел - home
и вижу что всё перепутано с правами!



Вот в
xfce4-terminal 0.8.7.1



mount /dev/sda3 /mnt


rimma@tamrik:~$ ls -All /mnt/home/
итого 32
drwx------ 50 tobik tobik 24576 мар 18 13:24 rimma
drwx------ 15 rimma  rimma   4096 мар 15 16:21 tobik
drwxr-xr-x  5 tobik tobik  4096 мар 15 17:10 y_walpappers



rimma@tamrik:~$ ls -All /mnt/home/rimma/
ls: невозможно открыть каталог '/mnt/home/rimma/': Отказано в доступе
(хотя на sda5 я сейчас пользователь rimma)




rimma@tamrik:~$ ls -All /mnt/home/tobik/
итого 100
-rw------- 1 rimma rimma     6 мар 15 16:21  .bash_history
......................

rimma@tamrik:~$

Ха а "чужого" - tobik-а разрешает просмотреть!

То же в
Thunar 1.6.14


Изнутри  Debian Stable 9_4 та же история (то есть если я нахожусь на
sda3 - Debian 9.4 Stable) - если оттуда примонтирую раздел sda5 с
Debian buster/sid Unstable.




Хотела написать об этой проблеме ещё пару лет назад, но поскольку надо
было писать на английском ....
Короче подумала, что кто-то заметит и напишет. Вот прошло время и "воз
и ныне там"!

Возможно этот баг уже зарегистирован, не смотрела, там сложно читать
:-((
Galina


Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Igor Chumak-2
In reply to this post by Galina Anikina

Знатный вброс.
Но это проблема не Debian, а того, кто его неправильно использует.
Во первых, внешний диск монтировался с правами root, а в linux, как известно, root может всё.

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Artem Chuprina-4
In reply to this post by Galina Anikina
Galina Anikina -> [hidden email]  @ Mon, 19 Mar 2018 07:43:40 +0300:

 > Кто поможет составить bug-рапорт на английском о "Проблеме с правами
 > доступа в Debian"? (или сам составит, а меня только упомянет? - то есть
 > на правах соавторства)

 > Я бы её отнесла к очень серьёзной проблеме!


 > Это продолжается уже несколько лет! Ранее когда-то такого не было -
 > было полное совпадение имён и соответственно разрешалось смотреть
 > только тот каталог, у которого совпадают пользователи - хотя и это -
 > грубое нарушение безопасности! Ведь к пример если есть человек с
 > фамилией Сидоров, то это не значит, что ему разрешено открывать двери
 > квартир других Сидоровых, где бы они не жили - в Москве, Омске и тд!
 > Или другой пример - если ключ от вашей квартиру подходит к чужой
 > квартире - это ещё не значит что вы имеете право войти в неё! :-)))


 > Ранее "было полное совпадение имён и соответственно разрешалось
 > смотреть только тот каталог, у которого совпадают пользователи" - не
 > могу сказать в какой операционной системе Linux, но было всё нормально
 > - так как пробовала -ставила разные - начиная от Slackware и тд.

 > Возможно это проблема не Debian, а самой программы, которая занимается
 > распределением прав доступа или устанавливает права доступа на
 > примонтированных разделах. Поскольку я не программист по Linux мне
 > сложно сказать - где происходит неувязка. Но её необходимо устранить -
 > это однозначно. Тем более в таком уважаемом дистибутиве, как Debian!


 > Суть в следующем:


 > нахожусь пользователем rimma на sda5 с установленной системой
 > Debian_Buster/sid__Unstable

 > примонтировала sda3 с Debian Stable 9_4 - чтобы wallpappers перебросить
 > с sda3 на sda5

 > И получается абсурд
 > я могу посмотреть (полазить в нём) каталог не такого же пользователя
 > (если он совпал по имени - например rimma), а чужого - другого
 > пользователя (например tobik-а)!
 > К примеру я сейчас rimma и нахожусь на sda5, примонтировала sda3, далее
 > смотрю тот соседний раздел - home
 > и вижу что всё перепутано с правами!

Этот багрепорт надо писать не на систему, а на Вашу политику
аутентификации. А того скорее - на Вашу недообразованность как
сисадмина. Я практически уверен, что Вы даже о понятии "политика
аутентификации" не задумывались. Этот багрепорт можно писать на русском.

"Результатом автоматизации бардака может быть только автоматизированный
бардак". (c) "Записки автоматизатора"

Почему сразу "политика аутентификации"? Потому что вообще говоря, если
компьютеров несколько, то система заведения пользователей и их
аутентификации может быть для них общей. В случае одного компьютера
обычно можно ограничиться политикой распределения uid'ов.

Инструменты дистрибутива могут обеспечить выполнение Вашей политики, но
не должны (в смысле "должны не") придумывать ее для Вас. Некое умолчание
у них есть, но оно совершенно справедливо рассчитано на один экземпляр
системы, и попытка подсунуть диск от другого экземпляра, не
сформулировав оную политику предварительно, приводит к закономерному
бардаку.

P.S. Поправить уже случившийся бардак можно. Но букварь прочесть для
этого все-таки придется. Ну, или платный саппорт :)

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Galina Anikina
In reply to this post by Grigory Fateyev-2
В Пн, 19/03/2018 в 08:37 +0300, Grigory Fateyev пишет:

> Это не проблема, а фича! Тут не в имени дело, а в UID. Посмотрите
> вывод id, по умолчанию в Debian, при установке, создаётся первый юзер
> с UID 1000. Похоже эти юзеры были созданны первыми при инсталяции
> системы и соответственно юзеры rimma и tobik имеют одинаковый UID.
>
> 19 марта 2018 г., 7:43 пользователь Galina Anikina <[hidden email]
> u> написал:
> > Кто поможет составить bug-рапорт на английском о "Проблеме с
> > правами
> > доступа в Debian"?

Вот ещё написал на эту тему -
Sergey Alyoshin <[hidden email]
Кому:Debian-L10N-russian <[hidden email]>


> По выводу ls ясно, что владелец /mnt/home/rimma tobik, а не rimma.

> Видимо у вас разные идентификаторы пользователя на разных системах,
> а проверка прав по идентификатору пользователя, не по имени.

> Скажем, на старой системе tobik UID 1000, rimma UID 1001, а на новой
> наоборот,
> потому что один пользователь был создан раньше другого. UID можно
> поменять.

> Кроме того при монтировании можно указать принудительно
идентификаторы
> группы и пользователя владельцев. Если хотите чтобы никто кроме вас
не
> смог просмотреть файловую систему, то шифруйте её.


> rimma@tamrik:~$ ls -All /mnt/home/tobik/
> итого 100
> -rw------- 1 rimma rimma     6 мар 15 16:21  .bash_history
> ......................
>
> rimma@tamrik:~$
>
> Ха а "чужого" - tobik-а разрешает просмотреть!

Потому что владелец "чужого" тут rimma.


> Хотела написать об этой проблеме ещё пару лет назад, но поскольку
надо
> было писать на английском ....
> Короче подумала, что кто-то заметит и напишет. Вот прошло время и
"воз
> и ныне там"!
>
> Возможно этот баг уже зарегистирован, не смотрела, там сложно читать

Это не ошибка, особенность.


---------------------

Да пользователи там и там были созданы в разное время-
то есть наоборот
На одном разделе допустим ввели 1-го и 2-го пользователя, при этом 1-ый
пользователь получил (на мой взгляд) излишние права - как первый и
поэтому на второй системе они были созданы наоборот.
НО !  Как может производиться монтирование только по UID? Не учитывая
имени пользователя? Получается, что производится усечённая проверка
прав пользователей на соседнем разделе только по UID. Сейчас подумаю,
какой аналог привести, чтобы было понятно. Например - в юридическом
смысле не будет являться полной идентификация человека только по
отпечатку пальца, без паспорта (в нашей стране) или другого документа
(в другой стране) и личного физически присутствия (как в банке при
получении кредита записывают на видео). То есть это не совсем
полноценная идентификация (с возможностью компроментаций).
Так и в этом случае - подмонтированная система монтируется получается
кое-как, с минимальной проверкой прав.

В данном случае вопрос шифрования находится ещё на стадии изучения, а
две системы установлены в качестве эксперимента на компе, где сам себе
хозяин.

Насчёт поменять UID - спасибо сделаю, но всё же хотелось бы, чтобы
проверялось не только по UID а и по имени пользователю и если они не
совпадают, то программа должна уведомить root-а в момент монтирования и
возможно предложить какое-то решение.
Это был бы логичный разумный вариант разрешения данного вопроса.
Кстати вот ещё пример на тему - обоснования зачем это надо-

Представьте школу и учитель информатики установил на один компьютер в
сети систему и ввёл пользователей 1 и 2. (Ну или если школа или кружок
маленькие - то установил на разных разделах одного компьютера разные
системы, чтобы продемонстрировать детям разные операционные системы)
Далее через некоторое время или учитель сменился или заболел и его
подменяли (причин может быть много) - другой человек установил систему
на другом компьютере - в этой же сети ввёл двух пользователей, но в
обратном порядке. Один ученик (любопытный) примонтирует соседний раздел
и попадёт к примеру в каталог учителя...

Или ещё пример - на домашнем компьютере установлены две системы -для
работы и для домашних развлечений, и там введены два пользователя -
муж-жена, брат-сестра, два соседа по съёмной квартире и тд, Я думаю
смысл понятен.
И предположим в описываемых ситуациях так же будут введены пользователи
наоборот (кроме этого надо учитывать тот факт, что не все учителя или
сопровождающие компьютерную технику в школах и в других учреждениях
знают на пятёрку, назубок, все команды и последствия их неправильного
ввода). Что мы в итоге имеем? Один (более продвинутый пользователь)
примонтирует соседний раздел и с удивлением обнаружит, что имеет доступ
к разделу жены и тд. Я думаю последствия очевидны.
Таким образом происходит компрометация другого человека, к которому вот
 таким образом "незаконно" кто-то вломился (то есть вломился в его
виртуальный дом и узнал много чего лишнего).
Я сознательно привела "такой" пример. Таким образом я пытаюсь всё же
доказать очевидное. Хотя я понимаю, что проще сделать вид, что проблемы
не существует.
Или если пользователь 2-ой хочет просмотреть каталог 1-го - где у них
совпадают UID, но не совпадают имена - надо выдать окно предупреждения
- что поскольку UID и имя пользователя не совпадают на 100 проентов, то
эту операцию может сделать только суперпользователь и отказать этому
желающему.
Такой вариант решения был был компромиссным и правильным.
Это не в адрес читателей нашей рассылки, а в адрес разработчиков.


 

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Igor Chumak-2
19.03.2018 10:56, Galina Anikina пишет:
В Пн, 19/03/2018 в 08:37 +0300, Grigory Fateyev пишет:
Это не проблема, а фича! Тут не в имени дело, а в UID. Посмотрите
вывод id, по умолчанию в Debian, при установке, создаётся первый юзер
с UID 1000. Похоже эти юзеры были созданны первыми при инсталяции
системы и соответственно юзеры rimma и tobik имеют одинаковый UID.

19 марта 2018 г., 7:43 пользователь Galina Anikina [hidden email] написал:
Кто поможет составить bug-рапорт на английском о "Проблеме с
правами
доступа в Debian"? 
Вот ещё написал на эту тему -
Sergey Alyoshin <[hidden email]
Кому:Debian-L10N-russian [hidden email]


По выводу ls ясно, что владелец /mnt/home/rimma tobik, а не rimma.

      
Видимо у вас разные идентификаторы пользователя на разных системах,
а проверка прав по идентификатору пользователя, не по имени.

      
Скажем, на старой системе tobik UID 1000, rimma UID 1001, а на новой
наоборот,
потому что один пользователь был создан раньше другого. UID можно 
поменять.

      
Кроме того при монтировании можно указать принудительно
идентификаторы
группы и пользователя владельцев. Если хотите чтобы никто кроме вас
не
смог просмотреть файловую систему, то шифруйте её.

rimma@tamrik:~$ ls -All /mnt/home/tobik/
итого 100
-rw------- 1 rimma rimma     6 мар 15 16:21  .bash_history
......................

rimma@tamrik:~$

Ха а "чужого" - tobik-а разрешает просмотреть!
Потому что владелец "чужого" тут rimma.


Хотела написать об этой проблеме ещё пару лет назад, но поскольку
надо
было писать на английском ....
Короче подумала, что кто-то заметит и напишет. Вот прошло время и
"воз
и ныне там"!

Возможно этот баг уже зарегистирован, не смотрела, там сложно читать
Это не ошибка, особенность.


---------------------

Да пользователи там и там были созданы в разное время-
то есть наоборот
На одном разделе допустим ввели 1-го и 2-го пользователя, при этом 1-ый 
пользователь получил (на мой взгляд) излишние права - как первый и
поэтому на второй системе они были созданы наоборот.
НО !  Как может производиться монтирование только по UID? Не учитывая
имени пользователя? Получается, что производится усечённая проверка
прав пользователей на соседнем разделе только по UID. Сейчас подумаю,
какой аналог привести, чтобы было понятно. Например - в юридическом
смысле не будет являться полной идентификация человека только по
отпечатку пальца, без паспорта (в нашей стране) или другого документа
(в другой стране) и личного физически присутствия (как в банке при
получении кредита записывают на видео). То есть это не совсем
полноценная идентификация (с возможностью компроментаций).
Так и в этом случае - подмонтированная система монтируется получается
кое-как, с минимальной проверкой прав.

В данном случае вопрос шифрования находится ещё на стадии изучения, а
две системы установлены в качестве эксперимента на компе, где сам себе
хозяин.

Насчёт поменять UID - спасибо сделаю, но всё же хотелось бы, чтобы
проверялось не только по UID а и по имени пользователю и если они не
совпадают, то программа должна уведомить root-а в момент монтирования и
возможно предложить какое-то решение.
Это был бы логичный разумный вариант разрешения данного вопроса.
Кстати вот ещё пример на тему - обоснования зачем это надо-

Представьте школу и учитель информатики установил на один компьютер в
сети систему и ввёл пользователей 1 и 2. (Ну или если школа или кружок
маленькие - то установил на разных разделах одного компьютера разные
системы, чтобы продемонстрировать детям разные операционные системы)
Далее через некоторое время или учитель сменился или заболел и его
подменяли (причин может быть много) - другой человек установил систему
на другом компьютере - в этой же сети ввёл двух пользователей, но в
обратном порядке. Один ученик (любопытный) примонтирует соседний раздел
и попадёт к примеру в каталог учителя...

Или ещё пример - на домашнем компьютере установлены две системы -для
работы и для домашних развлечений, и там введены два пользователя -
муж-жена, брат-сестра, два соседа по съёмной квартире и тд, Я думаю
смысл понятен.
И предположим в описываемых ситуациях так же будут введены пользователи
наоборот (кроме этого надо учитывать тот факт, что не все учителя или
сопровождающие компьютерную технику в школах и в других учреждениях 
знают на пятёрку, назубок, все команды и последствия их неправильного
ввода). Что мы в итоге имеем? Один (более продвинутый пользователь)
примонтирует соседний раздел и с удивлением обнаружит, что имеет доступ
к разделу жены и тд. Я думаю последствия очевидны.
Таким образом происходит компрометация другого человека, к которому вот
 таким образом "незаконно" кто-то вломился (то есть вломился в его
виртуальный дом и узнал много чего лишнего).
Я сознательно привела "такой" пример. Таким образом я пытаюсь всё же
доказать очевидное. Хотя я понимаю, что проще сделать вид, что проблемы
не существует. 
Или если пользователь 2-ой хочет просмотреть каталог 1-го - где у них
совпадают UID, но не совпадают имена - надо выдать окно предупреждения
- что поскольку UID и имя пользователя не совпадают на 100 проентов, то
эту операцию может сделать только суперпользователь и отказать этому
желающему.
Такой вариант решения был был компромиссным и правильным.
Это не в адрес читателей нашей рассылки, а в адрес разработчиков.


 


Бардак.

Если необходима приватность данных - необходимо использовать шифрование. Точка. В любом другом случае, особенно если возможен dual boot, или есть права root (Administrator) - данные любого пользователя доступны. И под linux, и под windows.

В  вашем случае, чтобы UID'ы не пересекались - в файле /etc/login.defs есть параметр UID_MIN. Установите его на разных системах в разное значение (1000,2000,3000) - и диапазоны UID'ов будут разными.

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Eugene Berdnikov
In reply to this post by Galina Anikina
On Mon, Mar 19, 2018 at 11:56:08AM +0300, Galina Anikina wrote:
> Или если пользователь 2-ой хочет просмотреть каталог 1-го - где у них
> совпадают UID, но не совпадают имена - надо выдать окно предупреждения
> - что поскольку UID и имя пользователя не совпадают на 100 проентов, то
> эту операцию может сделать только суперпользователь и отказать этому
> желающему.

 Совпадение имён, то есть некоторых текстовых строк (последовательностей
 байт переменной длины) ничем не лучше совпадению uid'ов, однако кардинально
 хуже в плане эффективности операций сравнения: (short) int сравниваются
 на порядок или два быстрее. А подделать имя столь же легко, как и uid.

> Такой вариант решения был был компромиссным и правильным.

 Тогда следует добавить, что 99.9% случаев он был бы бесполезной тратой
 ресурсов. Ваш случай совсем нетипичный, можно сказать, ненормальный.

> Это не в адрес читателей нашей рассылки, а в адрес разработчиков.

 Разработчики юниксов сделали всё правильно: они выделили наиболее
 употребимый шаблон использования системы и для него нашли простое
 и эффективное решение. "Просто глупо заниматься оптимизацией под
 экзотические и редко встречающиеся задачи" (с) Линус.
--
 Eugene Berdnikov

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Stanislav Vlasov-2
In reply to this post by Galina Anikina
19 марта 2018 г., 13:56 пользователь Galina Anikina
<[hidden email]> написал:

> Да пользователи там и там были созданы в разное время-
> то есть наоборот
> На одном разделе допустим ввели 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 | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

yuri.nefedov
In reply to this post by Galina Anikina
On Mon, 19 Mar 2018, Galina Anikina wrote:
... skip ...

  Есть хорошая книга: Керниган Б., Пайк Р. UNIX Программное окружение
  Глава 2: Файловая система. Всего 35 страниц.

  Очень рекомендую.
Ю.

  p.s. 2.4 Права доступа:

  Если вы настолько дисциплинированны, что храните в системе
  свою любовную переписку, может быть, даже рассортированную
  по каталогам...
Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Victor Wagner
In reply to this post by Stanislav Vlasov-2
On Mon, 19 Mar 2018 14:31:14 +0500
Stanislav Vlasov <[hidden email]> wrote:


>
> Потому что подключение диска от другой системы - нештатная ситуация.
> Если хотите, чтоб при подобном не было доступа к чужим данным -
> шифруйте. А для локального /home - достаточно проверять uid.
> Тем более, в файловой системе нет такого атрибута, как имя
> пользователя.

Времена изменились. Теперь появились съемные носители с терабайтными
емкостями, на которых хочется иметь нормальную файловую систему.
Потому что поделия вроде FAT не умеют нормально работаь с такими
объемами.

В свое время, когда появились CD-ROM, разработчики RockRidge
extensions к стандарту iso9660 подумали над этим вопросом. Результат
их размышлления имеется в виде ключика -r у wodim - всем файлам
принудительно обнуляется UID и GID, и проставляются права 444 (а
каталогам 555). Потому что на съемном носителе, право читать который
имеет кто угодно - это единственная осмысленная система прав.

Примерно то же самое у нас сделано путем задания опций монтирования
для дисков с FAT. Но вот не тянет FAT нынешних сменных дисков, надо
ext4 или NTFS. А для них никто этот use case не продумывал.
--

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Stanislav Vlasov-2
19 марта 2018 г., 15:44 пользователь Victor Wagner <[hidden email]> написал:

>> Потому что подключение диска от другой системы - нештатная ситуация.
>> Если хотите, чтоб при подобном не было доступа к чужим данным -
>> шифруйте. А для локального /home - достаточно проверять uid.
>> Тем более, в файловой системе нет такого атрибута, как имя
>> пользователя.
>
> Времена изменились. Теперь появились съемные носители с терабайтными
> емкостями, на которых хочется иметь нормальную файловую систему.
> Потому что поделия вроде FAT не умеют нормально работаь с такими
> объемами.

Угу. А фс - не изменились. Даже в ntfs нет атрибута "имя
пользователя", если правильно помню.
Но съёмный носитель обычно не содержит домашний каталог от соседней
рабочей станции и у него противоположные проблемы, которые я поскипал.

--
Stanislav
Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Victor Wagner
On Mon, 19 Mar 2018 16:35:03 +0500
Stanislav Vlasov <[hidden email]> wrote:

> 19 марта 2018 г., 15:44 пользователь Victor Wagner
> <[hidden email]> написал:
>
> >> Потому что подключение диска от другой системы - нештатная
> >> ситуация. Если хотите, чтоб при подобном не было доступа к чужим
> >> данным - шифруйте. А для локального /home - достаточно проверять
> >> uid. Тем более, в файловой системе нет такого атрибута, как имя
> >> пользователя.  
> >
> > Времена изменились. Теперь появились съемные носители с терабайтными
> > емкостями, на которых хочется иметь нормальную файловую систему.
> > Потому что поделия вроде FAT не умеют нормально работаь с такими
> > объемами.  
>
> Угу. А фс - не изменились. Даже в ntfs нет атрибута "имя
> пользователя", если правильно помню.

В NTFS есть SID.

> Но съёмный носитель обычно не содержит домашний каталог от соседней
> рабочей станции и у него противоположные проблемы, которые я поскипал.

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


Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Dmitry Alexandrov
In reply to this post by Victor Wagner
> Времена изменились. Теперь появились съемные носители с терабайтными
> емкостями, на которых хочется иметь нормальную файловую систему.
> Потому что поделия вроде FAT не умеют нормально работаь с такими
> объемами.
>
> В свое время, когда появились CD-ROM, разработчики RockRidge
> extensions к стандарту iso9660 подумали над этим вопросом. Результат
> их размышлления имеется в виде ключика -r у wodim - всем файлам
> принудительно обнуляется UID и GID, и проставляются права 444 (а
> каталогам 555). Потому что на съемном носителе, право читать который
> имеет кто угодно - это единственная осмысленная система прав.
>
> Примерно то же самое у нас сделано путем задания опций монтирования
> для дисков с FAT. Но вот не тянет FAT нынешних сменных дисков, надо
> ext4 или NTFS.

UDF же!

> А для них никто этот use case не продумывал.

Для NTFS (по крайней мере, для той, которая не в Линуксе, а которая 3g) вроде продумывал, не?  Есть у нее опции uid и gid.  А значит, как и с UDF, носитель смотнированный пользователем, будет целиком с его правами.   Ну, по крайней мере, должен быть.  Если нет, то надо думать, что это проблема на стороне udisks.
Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Igor Chumak-2
In reply to this post by Victor Wagner
19.03.2018 14:03, Victor Wagner пишет:

> On Mon, 19 Mar 2018 16:35:03 +0500
> Stanislav Vlasov <[hidden email]> wrote:
>
>> 19 марта 2018 г., 15:44 пользователь Victor Wagner
>> <[hidden email]> написал:
>>
>>>> Потому что подключение диска от другой системы - нештатная
>>>> ситуация. Если хотите, чтоб при подобном не было доступа к чужим
>>>> данным - шифруйте. А для локального /home - достаточно проверять
>>>> uid. Тем более, в файловой системе нет такого атрибута, как имя
>>>> пользователя.
>>> Времена изменились. Теперь появились съемные носители с терабайтными
>>> емкостями, на которых хочется иметь нормальную файловую систему.
>>> Потому что поделия вроде FAT не умеют нормально работаь с такими
>>> объемами.
>> Угу. А фс - не изменились. Даже в ntfs нет атрибута "имя
>> пользователя", если правильно помню.
> В NTFS есть SID.

SID не цифровая подпись,  насколько я помню, администратор может стать
владельцем файла.

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Artem Chuprina-4
In reply to this post by Galina Anikina
Galina Anikina -> Grigory Fateyev  @ Mon, 19 Mar 2018 11:56:08 +0300:

 > НО !  Как может производиться монтирование только по UID? Не учитывая
 > имени пользователя? Получается, что производится усечённая проверка
 > прав пользователей на соседнем разделе только по UID.

На файловой системе, сюрприз, никаких других данных, кроме uid, просто
нет. Выбор простой - либо монтируем по uid, либо не монтируем вообще.

Тот факт, что на этом разделе еще, может быть, случайно, где-то
затесался еще и /etc/passwd от той системы - чистая случайность (в
аккуратных разбиениях диска /etc/passwd и пользовательские файлы, ага,
на разных разделах), полагаться на это не следует.

У винды в этом месте вместо uid'ов GUID'ы. У нее в результате обратная
проблема - при монтировании диска не от той системы прав нет ни у кого,
даже у админа. Имена совпадают (но система про это не в курсе, имен в
файловой системе точно так же нет), гуиды - нет. До свидания.

Бывает еще IBM с ее RSBAC, если не ошибаюсь. Где если продолбал пароль -
всё, способов доступа к данным нет вообще никаких. С шифрованной FS в
линуксе будет аналогично.

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

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Stanislav Vlasov-2
In reply to this post by Victor Wagner
19 марта 2018 г., 17:03 пользователь Victor Wagner <[hidden email]> написал:

>> > Времена изменились. Теперь появились съемные носители с терабайтными
>> > емкостями, на которых хочется иметь нормальную файловую систему.
>> > Потому что поделия вроде FAT не умеют нормально работаь с такими
>> > объемами.
>>
>> Угу. А фс - не изменились. Даже в ntfs нет атрибута "имя
>> пользователя", если правильно помню.

> В NTFS есть SID.

Это всё равно не имя пользователя, хоть и однозначно идентифицирует
его в конкретной системе.

>> Но съёмный носитель обычно не содержит домашний каталог от соседней
>> рабочей станции и у него противоположные проблемы, которые я поскипал.
>
> А если содержит, то это аварийная ситуация (например спасение
> информации с диска сдохшей машины) и пользователь сам хочет чтобы рут
> от машины, куда подключен диск, смог прочитать и скопировать его файлы.

Вот именно. А вопрос у дамы изначально противоположный, не дать доступ.

--
Stanislav
Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Galina Anikina
In reply to this post by yuri.nefedov
В Пн, 19/03/2018 в 17:46 +0800, [hidden email] пишет:

> On Mon, 19 Mar 2018, Galina Anikina wrote:
> ... skip ...
>
>   Есть хорошая книга: Керниган Б., Пайк Р. UNIX Программное окружение
>   Глава 2: Файловая система. Всего 35 страниц.
>
>   Очень рекомендую.
> Ю.
>
>   p.s. 2.4 Права доступа:
>
>   Если вы настолько дисциплинированны, что храните в системе
>   свою любовную переписку, может быть, даже рассортированную
>   по каталогам...

Обший смысл поняла - пользователь недосмотрел и допустил сам создание
такой ситуации, когда у него возникала такая ситуация - то есть как бы
путаются пользователи. Поэтому на будущее надо быть внимательнее и
помнить кого первого создал или зазубрить ключи к строке mount .... с
установкой UID. И вообще иметь на будущее в виду, что при работе с
файловыми системами важнее UID, а не имена пользователей.
У пользователя, который не работает на постоянной основе как
администратор UNIX-систем такие ситуации изредка, но могут случиться.
Предусмотреть все возможные случаи, которые могут возникать у
пользователей для программистов не представляется возможным. То есть
это не баг, а  особенности файловой системы и конкретный случай,
возникший по недосмотру (неважно - вольному или невольному)
пользователя.
За указание книги спасибо, не видела такую, буду иметь в виду на
будущее.

Всем спасибо за ответы.



Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

artiom
In reply to this post by Artem Chuprina-4


19.03.2018 09:19, Artem Chuprina пишет:

> Galina Anikina -> [hidden email]  @ Mon, 19 Mar 2018 07:43:40 +0300:
>
>  > Кто поможет составить bug-рапорт на английском о "Проблеме с правами
>  > доступа в Debian"? (или сам составит, а меня только упомянет? - то есть
>  > на правах соавторства)
>
>  > Я бы её отнесла к очень серьёзной проблеме!
>
>
>  > Это продолжается уже несколько лет! Ранее когда-то такого не было -
>  > было полное совпадение имён и соответственно разрешалось смотреть
>  > только тот каталог, у которого совпадают пользователи - хотя и это -
>  > грубое нарушение безопасности! Ведь к пример если есть человек с
>  > фамилией Сидоров, то это не значит, что ему разрешено открывать двери
>  > квартир других Сидоровых, где бы они не жили - в Москве, Омске и тд!
>  > Или другой пример - если ключ от вашей квартиру подходит к чужой
>  > квартире - это ещё не значит что вы имеете право войти в неё! :-)))
>
>
>  > Ранее "было полное совпадение имён и соответственно разрешалось
>  > смотреть только тот каталог, у которого совпадают пользователи" - не
>  > могу сказать в какой операционной системе Linux, но было всё нормально
>  > - так как пробовала -ставила разные - начиная от Slackware и тд.
>
>  > Возможно это проблема не Debian, а самой программы, которая занимается
>  > распределением прав доступа или устанавливает права доступа на
>  > примонтированных разделах. Поскольку я не программист по Linux мне
>  > сложно сказать - где происходит неувязка. Но её необходимо устранить -
>  > это однозначно. Тем более в таком уважаемом дистибутиве, как Debian!
>
>
>  > Суть в следующем:
>
>
>  > нахожусь пользователем rimma на sda5 с установленной системой
>  > Debian_Buster/sid__Unstable
>
>  > примонтировала sda3 с Debian Stable 9_4 - чтобы wallpappers перебросить
>  > с sda3 на sda5
>
>  > И получается абсурд
>  > я могу посмотреть (полазить в нём) каталог не такого же пользователя
>  > (если он совпал по имени - например rimma), а чужого - другого
>  > пользователя (например tobik-а)!
>  > К примеру я сейчас rimma и нахожусь на sda5, примонтировала sda3, далее
>  > смотрю тот соседний раздел - home
>  > и вижу что всё перепутано с правами!
>
> Этот багрепорт надо писать не на систему, а на Вашу политику
> аутентификации. А того скорее - на Вашу недообразованность как
> сисадмина. Я практически уверен, что Вы даже о понятии "политика
> аутентификации" не задумывались. Этот багрепорт можно писать на русском.
>
> "Результатом автоматизации бардака может быть только автоматизированный
> бардак". (c) "Записки автоматизатора"
>
Ну вот опять...
Я тоже сначала думал, что это вброс.
Но поискать не мешало бы: по-ходу, это переводчица разного в Debian.

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

artiom
In reply to this post by Galina Anikina
Внесу свои пять копеек.

19.03.2018 11:56, Galina Anikina пишет:
>
... skipped ...

> Представьте школу и учитель информатики установил на один компьютер в
> сети систему и ввёл пользователей 1 и 2. (Ну или если школа или кружок
> маленькие - то установил на разных разделах одного компьютера разные
> системы, чтобы продемонстрировать детям разные операционные системы)
> Далее через некоторое время или учитель сменился или заболел и его
> подменяли (причин может быть много) - другой человек установил систему
> на другом компьютере - в этой же сети ввёл двух пользователей, но в
> обратном порядке. Один ученик (любопытный) примонтирует соседний раздел
> и попадёт к примеру в каталог учителя...
>
> Или ещё пример - на домашнем компьютере установлены две системы -для
> работы и для домашних развлечений, и там введены два пользователя -
> муж-жена, брат-сестра, два соседа по съёмной квартире и тд, Я думаю
> смысл понятен.
> И предположим в описываемых ситуациях так же будут введены пользователи
> наоборот (кроме этого надо учитывать тот факт, что не все учителя или
> сопровождающие компьютерную технику в школах и в других учреждениях
> знают на пятёрку, назубок, все команды и последствия их неправильного
> ввода). Что мы в итоге имеем? Один (более продвинутый пользователь)
> примонтирует соседний раздел и с удивлением обнаружит, что имеет доступ
> к разделу жены и тд. Я думаю последствия очевидны.
Не думаю, что последствия очевидны.

> Таким образом происходит компрометация другого человека, к которому вот
>  таким образом "незаконно" кто-то вломился (то есть вломился в его
> виртуальный дом и узнал много чего лишнего).
> Я сознательно привела "такой" пример. Таким образом я пытаюсь всё же
> доказать очевидное. Хотя я понимаю, что проще сделать вид, что проблемы
> не существует.
> Или если пользователь 2-ой хочет просмотреть каталог 1-го - где у них
> совпадают UID, но не совпадают имена - надо выдать окно предупреждения
> - что поскольку UID и имя пользователя не совпадают на 100 проентов, то
> эту операцию может сделать только суперпользователь и отказать этому
> желающему.
> Такой вариант решения был был компромиссным и правильным.
> Это не в адрес читателей нашей рассылки, а в адрес разработчиков.
Имена не имеют значения и являются усложнением.
Не мешало бы задуматься, перед тем, как вносить предложения, как
пользователи изначально работали на системах терминального доступа
(которые застал Unix), в которых один компьютер обслуживал много
пользователей через прямые dial-up подключения, как сейчас работают
сервера, обслуживающие многих клиентов (которые, в основном на Unix-like
и в большинстве на Linux), суперкомпьютеры, разделяющие задачи, и вообще
весь корпоративный сегмент (ведь там пользователей несколько больше, чем 2).

Ни у кого не возникало таких вопросов и данной проблемы.
Не означает ли это, что проблемы нет?
И что либо вы не можете корректно сформулировать требования, либо не
знаете существующих методов решения "проблемы"?

Reply | Threaded
Open this post in threaded view
|

Re: Проблема с правами доступа в Debian

Galina Anikina
In reply to this post by artiom
Создала новых пользователей (uid - следующие по счёту) и заблокировала
двух существующих ранее (скопировав перед этим от них данные). На
будущее - запомню про uid - об этом надо знать, когда устанавливаешь
две и более систем на один жёсткий диск.