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

[Gali Anikina]

В Пн, 19/03/2018 в 08:55 +0300, Sergey Alyoshin пишет:
> 2018-03-19 7:50 GMT+03:00 Galina Anikina :
> > Суть в следующем:
> > 
> > нахожусь пользователем 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)
> 
> По выводу 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.
> 
> 
> > Хотела написать об этой проблеме ещё пару лет назад, но поскольку
> > надо
> > было писать на английском 
> > Короче подумала, что кто-то заметит и напишет. Вот прошло время и
> > "воз
> > и ныне там"!
> > 
> > Возможно этот баг уже зарегистирован, не смотрела, там сложно
> > читать
> 
> Это не ошибка, особенность.

Сделала так -

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

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

[Gali Anikina]

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

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

[artiom]

Внесу свои пять копеек.

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

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

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

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

[artiom]

19.03.2018 09:19, Artem Chuprina пишет:
> Galina Anikina -> debian-russian@lists.debian.org  @ 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.

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

[Galina Anikina]

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

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

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

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

[Galina Anikina]

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

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

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

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

[Stanislav Vlasov]

19 марта 2018 г., 17:03 пользователь Victor Wagner  написал:

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

> В NTFS есть SID.

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

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

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

-- 
Stanislav

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

[Artem Chuprina]

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 в
линуксе будет аналогично.

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

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

[Igor Chumak]

19.03.2018 14:03, Victor Wagner пишет:

On Mon, 19 Mar 2018 16:35:03 +0500
Stanislav Vlasov  wrote:


19 марта 2018 г., 15:44 пользователь Victor Wagner
 написал:


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

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

Угу. А фс - не изменились. Даже в ntfs нет атрибута "имя
пользователя", если правильно помню.

В NTFS есть SID.


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

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

[Dmitry Alexandrov]

> Времена изменились. Теперь появились съемные носители с терабайтными
> емкостями, на которых хочется иметь нормальную файловую систему.
> Потому что поделия вроде 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.

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

[Victor Wagner]

On Mon, 19 Mar 2018 16:35:03 +0500
Stanislav Vlasov  wrote:

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

В NTFS есть SID.

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

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

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

[Stanislav Vlasov]

19 марта 2018 г., 15:44 пользователь Victor Wagner  написал:

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

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

-- 
Stanislav

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

[Victor Wagner]

On Mon, 19 Mar 2018 14:31:14 +0500
Stanislav Vlasov  wrote:


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

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

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

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

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

[Sergey Alyoshin]

2018-03-19 11:56 GMT+03:00 Galina Anikina :

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

Для такого есть способы сетевой аутентификации пользователей.


> Или ещё пример - на домашнем компьютере установлены две системы -для
> работы и для домашних развлечений, и там введены два пользователя -
> муж-жена, брат-сестра, два соседа по съёмной квартире и тд, Я думаю
> смысл понятен.

Так во всех UNIX'ах.

Думаю, максимум что можно сделать, предупреждать при установке системы,
что может быть такая ситуация и описать её в руководстве по установке.


> Или если пользователь 2-ой хочет просмотреть каталог 1-го - где у них
> совпадают UID, но не совпадают имена - надо выдать окно предупреждения
> - что поскольку UID и имя пользователя не совпадают на 100 проентов, то
> эту операцию может сделать только суперпользователь и отказать этому
> желающему.
> Такой вариант решения был был компромиссным и правильным.

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

Переставите диск в другой компьютер, кто-то будет знать пароль
суперпользователя и спокойно просмотрит ваши файлы (и tobika тоже). Хотите
приватности -- шифруйте (если надолго, то и резервные копии).

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

[yuri . nefedov]

On Mon, 19 Mar 2018, Galina Anikina wrote:
... skip ...

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

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

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

 Если вы настолько дисциплинированны, что храните в системе
 свою любовную переписку, может быть, даже рассортированную
 по каталогам...

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

[Stanislav Vlasov]

19 марта 2018 г., 13:56 пользователь Galina Anikina
 написал:

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

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

[Eugene Berdnikov]

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

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

[Igor Chumak]

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  написал:

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

Вот ещё написал на эту тему -
Sergey Alyoshin 



По выводу 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, но не 

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

[Galina Anikina]

В Пн, 19/03/2018 в 08:37 +0300, Grigory Fateyev пишет:
> Это не проблема, а фича! Тут не в имени дело, а в UID. Посмотрите
> вывод id, по умолчанию в Debian, при установке, создаётся первый юзер
> с UID 1000. Похоже эти юзеры были созданны первыми при инсталяции
> системы и соответственно юзеры rimma и tobik имеют одинаковый UID.
> 
> 19 марта 2018 г., 7:43 пользователь Galina Anikina  u> написал:
> > Кто поможет составить bug-рапорт на английском о "Проблеме с
> > правами
> > доступа в Debian"? 

Вот ещё написал на эту тему -
Sergey Alyoshin 


> По выводу 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-го - где у 

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

[Galina Anikina]

В Пн, 19/03/2018 в 08:37 +0300, Grigory Fateyev пишет:
> Это не проблема, а фича! Тут не в имени дело, а в UID. Посмотрите
> вывод id, по умолчанию в Debian, при установке, создаётся первый юзер
> с UID 1000. Похоже эти юзеры были созданны первыми при инсталяции
> системы и соответственно юзеры rimma и tobik имеют одинаковый UID.
> 
> 19 марта 2018 г., 7:43 пользователь Galina Anikina  u> написал:
> > Кто поможет составить bug-рапорт на английском о "Проблеме с
> > правами
> > доступа в Debian"? 

Вот ещё написал на эту тему -
Sergey Alyoshin 


> По выводу 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-го - где у 

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

[Artem Chuprina]

Galina Anikina -> debian-russian@lists.debian.org  @ 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. Поправить уже случившийся бардак можно. Но букварь прочесть для
этого все-таки придется. Ну, или платный саппорт :)

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

[Игорь Чумак]

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

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

[Sergey Alyoshin]

2018-03-19 7:50 GMT+03:00 Galina Anikina :
> Суть в следующем:
>
> нахожусь пользователем 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)

По выводу 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.


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

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

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

[Grigory Fateyev]

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

19 марта 2018 г., 7:43 пользователь 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
>
>