From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <klark.devel@gmail.com>
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
 sa.local.altlinux.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
 DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no
 version=3.4.1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1727477201; x=1728082001; darn=lists.altlinux.org; 
 h=content-transfer-encoding:in-reply-to:from:content-language
 :references:to:subject:user-agent:mime-version:date:message-id:from
 :to:cc:subject:date:message-id:reply-to;
 bh=Q/qWfR3aKMrUraTBYgaujbIIuxi6/RWaVGfmTaKXDfc=;
 b=ZoIvYKZHjrGNrggCJeJUZjT5Ri54kieQnm1nhsDHKwKVMTdqswQemxH2UHwnMuwf36
 Yzd4E/EejeHqPTx5qqHF7YDSZR4dWXJKlO7RlyEvU4+jH6N89cGa7tnlC1zgiQhvfwW+
 xDjv29jW5PrDFYQo1hhwOPUCW9/qvPo3Ir6ZD7y+k8xJdTQa2zovSsWG1myPV4oq3KJn
 K2ZIAKzANA/mmqP84/GGcnCR6n6YTWW0pHUd1FgJ9I+Mocj4FcnZ8QQqfwCoADzwnsWG
 ulpa0kaAXwqz6XT2CyQii9iXlAKiBe8WApNRJOV0z/nGtOClXXIxGYnVyrY0hVeGF3yw
 Wq9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1727477201; x=1728082001;
 h=content-transfer-encoding:in-reply-to:from:content-language
 :references:to:subject:user-agent:mime-version:date:message-id
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=Q/qWfR3aKMrUraTBYgaujbIIuxi6/RWaVGfmTaKXDfc=;
 b=cSarGMm5DtVtxuzqVAPbZgDF+Yknmom6l6JTCBzOPaAV15SdIRfa3j5SuKd2iWd7Jp
 Qaox+QykHdOAIx83SgVytPun2jOIBJjiOVfRhO6bTrcphEaic8Bvu1CPXUb67LGoEIz0
 m5V1BS2ShlwdZgXLfI5KPqdvpmj/wc0lcuJZgLj5IZnuvJZWovFycvf8FK1n4/6vGgX+
 o/o5BxEjaBvLkk9+79RUicrAWt7xKAVdfIS7nVe9pdNeg0yM4vxdk7myJZivmbaCados
 tZsUg3WUl5FZPKHZEJdI6KjsqOdoK1HRqGaheFyprbnYSY5xTHp02gNXdTpiAbC9TRoA
 XvJw==
X-Gm-Message-State: AOJu0Yxg64lvQCu8t/RmFhwHBTwXOEez/8UcsZkZZ6r/YoDMes4T4T6T
 /5jsQ1Pr645Ajnq2CKcP1MjBD3wKFpERLy7P6R9ZEACfJwzI1sv2j6rvQg==
X-Google-Smtp-Source: AGHT+IHZOR8v7NXSKTZ98p65ql69RFMiRfAOykvDZAnHuNqaBSIeheWCB5UtB6w1RnFkjdrZSSbXZw==
X-Received: by 2002:ac2:4c53:0:b0:536:553f:3ef9 with SMTP id
 2adb3069b0e04-5389fc44d99mr3213280e87.27.1727477200644; 
 Fri, 27 Sep 2024 15:46:40 -0700 (PDT)
Message-ID: <62506b7c-9cdf-4dfc-bf11-fb8d5e3b4e15@gmail.com>
Date: Sat, 28 Sep 2024 01:46:36 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: devel@lists.altlinux.org
References: <20240927135731.52d72d16@legato>
 <305399cb-ae32-4019-b46e-62ec8f4e440a@basealt.ru>
 <20240927151805.12b8ec11@legato>
 <ee08f6fc-c100-4a7d-a158-7d1b494eb128@gmail.com>
 <20240928005714.5278d068@legato>
Content-Language: ru, en-US
From: Leonid Krivoshein <klark.devel@gmail.com>
In-Reply-To: <20240928005714.5278d068@legato>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [devel] =?utf-8?b?0KHQvNC10L3QsCBvd25lcnNoaXAg0LIgL2Rldi8q?=
X-BeenThere: devel@lists.altlinux.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ALT Linux Team development discussions <devel@lists.altlinux.org>
List-Id: ALT Linux Team development discussions <devel.lists.altlinux.org>
List-Unsubscribe: <https://lists.altlinux.org/mailman/options/devel>,
 <mailto:devel-request@lists.altlinux.org?subject=unsubscribe>
List-Archive: <http://lists.altlinux.org/pipermail/devel>
List-Post: <mailto:devel@lists.altlinux.org>
List-Help: <mailto:devel-request@lists.altlinux.org?subject=help>
List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/devel>,
 <mailto:devel-request@lists.altlinux.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2024 22:46:45 -0000
Archived-At: <http://lore.altlinux.org/devel/62506b7c-9cdf-4dfc-bf11-fb8d5e3b4e15@gmail.com/>
List-Archive: <http://lore.altlinux.org/devel/>
List-Post: <mailto:devel@altlinux.org>


On 9/28/24 00:57, Paul Wolneykien wrote:
> Ð’ Fri, 27 Sep 2024 22:52:29 +0300
> Leonid Krivoshein <klark.devel@gmail.com> пишет:
>
>> Привет!
>>
>>
>> On 9/27/24 15:18, Paul Wolneykien wrote:
>>> Ð’ Fri, 27 Sep 2024 14:54:31 +0300
>>> Danil Shein <dshein@basealt.ru> пишет:
>>>   
>>>> Интересное исследование.
>>>> И вы наверняка затронули актуальную для вас проблему.
>>>>
>>>> Однако в моём поле зрения уже много лет нет ни одного компьютера с
>>>> оптическим приводом вообще.
>>>     По мне, так сам принцип временной (!) смены ownership чего-то в
>>> /dev/* выглядит как ужос-ужос. CD --- это просто иллюстрация. Вероятно,
>>> нужно сменить тему письма.
>> Аналогичные недоумения пользователей относительно владельца, группы и
>> прав доступа в пакете alterator-ports-access. Просто, кому какое дело в
>> современном десктопном дистрибутиве с polkit+udisks2, какие там права у
>> устройств в /dev, эта парочка обеспечит любые права независимо от прав
>> пользователя на устройство.
>    Ну, не совсем: сделать образ диска и даже прожечь диск можно (и
> нужно?) без монтирования.

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

Возвращаясь к теме сабжа: если бы не правила udev, все устройства 
принадлежали бы root и имели некое дефолтное значение прав доступа. Но 
что даёт их изменение при куче способов обойти эти ограничения.

>> Плюс: опции пользовательского монтирования в /etc/fstab остались за
>> кадром исследования.
>    Наверное, это минус данного исследования, а не его плюс. :-)
>
>
>>>> Они как бы вымерли лет 5 назад.
>>>> Как артефакт имеется в наличии внешний USB привод, но и он давно пылится
>>>> без дела.
>>>>
>>>> 27.09.2024 13:57, Paul Wolneykien пишет:
>>>>>      Всем привет.
>>>>>
>>>>>      Мне тут понадобилось разобраться, почему членство пользователя в
>>>>> группе "cdrom" не регламентирует доступ к оптическому приводу, как
>>>>> написано в документации к одному из наших дистрибутивов. Было ясно,
>>>>> что документация устарела, и нужно было во всём разобраться.
>>>>>
>>>>>      Начал я с проверки доступа к самому устройству /dev/cdrom. Именно тут
>>>>> начались главные сюрпризы. В самом деле! Если на вашем компьютере есть
>>>>> оптический привод, не поленитесь, скажите `ls -l /dev/sr0`. Я, честно
>>>>> говоря, ожидал увидеть там "brw-rw----+ 1 root cdrom". Но вместо этого
>>>>> там с большой долей вероятности окажется "brw-rw----+ 1 <ваше_имя>
>>>>> cdrom". Получается, что сколько не удаляй пользователя из группы
>>>>> "cdrom", а доступ к устройству у него всё равно будет, поскольку он
>>>>> owner данного файла устройства. Это, значит, во-первых, что если
>>>>> документация на систему говорит нам, что доступ к CD/DVD
>>>>> регламентируется членством в группе "cdrom", то это не правда. А
>>>>> во-вторых, что нужно выяснить, что же происходит.
>>>>>
>>>>>      Виновником смены ownership оказался модуль pam_console.so. Не готов
>>>>> сейчас оценить, насколько полезную работу он сейчас делает, возможно
>>>>> для некоторых устройств он всё ещё нужен, но на современных системах
>>>>> менять права доступа к /dev/cdrom таким образом явно избыточно (это,
>>>>> если мы вообще принимаем, что нужно менять ownership). Отключить данный
>>>>> эффект можно, отредактировав конфигурационный файл
>>>>> /etc/security/console.perms.d/50-default.perms (строки "cdrom" и
>>>>> "burner" заодно).
>>>>>
>>>>>      (Хорошо бы, конечно, не редактировать данный файл, а добавить
>>>>> соседний, переопределяющий его. Но я пока не придумал, как написать
>>>>> такой вариант, который бы удалял ненужные действия с cdrom,
>>>>> определённые в 50-defaults.perms.)
>>>>>
>>>>>      После редактирования 50-default.perms права на /dev/sr0 вроде бы
>>>>> приходят к ожидаемому виду "brw-rw----+ 1 root cdrom". Что будет,
>>>>> если теперь удалить пользователя из группы "cdrom" (usermod -r -G
>>>>> cdrom ...)? Я снова надеялся, что в доступе будет отказано. Однако, на
>>>>> современных наших системах, это предположение снова оказывается ложным.
>>>>> Натурально, права на /dev/sr0 только у root, а пользователь спокойно
>>>>> управляет лотком (команда eject) и даже может сделать образ диска
>>>>> (dd if=/dev/sr0 ...)! Хорошо ли это? То, что eject и т.д. работают,
>>>>> конечно, неплохо. Плохо то, что происходит это против ожиданий
>>>>> администратора (по крайней мере такого как я).
>>>>>
>>>>>      Исследование и чтение документации показало, что на этот раз за
>>>>> странностями стоит systemd-logind в компании с udev. Но как же он это
>>>>> делает, когда на устройстве написано "root cdrom"?! Ответ можно узнать,
>>>>> введя команду `getfacl /dev/sr0`. Она покажет, что на /dev/sr0 есть
>>>>> дополнительные права (файловый ACL).
>>>>>
>>>>>      Регулируется данный эффект файлом
>>>>> /usr/lib/udev/rules.d/70-uaccess.rules
>>>>> (там есть строчки про "optical drives"). Смысл в том, что если udev
>>>>> выставляет для данного устройства теги "uaccess" и "seat", то затем
>>>>> systemd-logind присоединяет устройство к рабочему месту пользователя
>>>>> (loginctl seat-status ...) и выполняет setfacl с выдачей персонального
>>>>> доступа (rw) к этому файлу.
>>>>>
>>>>>      Обращаю внимание, что документация про "uaccess" есть у RedHat и у
>>>>> Астры:
>>>>>
>>>>>      *https://wiki.astralinux.ru/pages/viewpage.action?pageId=217187404
>>>>>      *https://access.redhat.com/articles/3148751
>>>>>
>>>>>      Я пробовал искать слово "uaccess" по сайту docs.altlinux.org, но оно
>>>>> не нашлось. :(
>>>>>
>>>>>      Устранить данный эффект правильней всего созданием переопределяющего
>>>>> (override) файла в /etc/udev/rules.d/, обязательно с более поздним
>>>>> индексом, чем 70-*, например 99-uacess-override.rules и в нём удалить
>>>>> тег "uaccess" с устройства (в конце письма будет пример).
>>>>>
>>>>>      Дальше, последнее, что оставалось сделать, это решить вопрос с
>>>>> монтированием оптических дисков. Только этот момент во всей этой истории
>>>>> был для меня ожидаемым, потому что про udisks и polkit я кое-что знал.
>>>>> Решается добавлением "subject.isInGroup('cdrom')" в polkit с проверкой
>>>>> типа устройства.
>>>>>
>>>>>      Для чего я написал это длинное письмо? Во-первых, для информации, так
>>>>> как многое из вышеописанного не было для меня ожидаемым. А во-вторых,
>>>>> текущее поведение, сложившееся как мне кажется стихийно, требует
>>>>> осмысления и, возможно, модификации. Первое, что приходит на ум ---
>>>>> это отказ от pam_console.so в пользу systemd-logind (естественно,
>>>>> на системах с systemd). Но и пользователям SysV-init тоже стоит
>>>>> подумать, нужно ли вообще дарить пользователю все перечисленные в
>>>>> 50-default.perms устройства по случаю его входа в систему.
>>>>>
>>>>>      P. S. Обнаружил пакет polkit-rule-udisks2-mount, в котором
>>>>> игнорируется разделение на "mount" и "mount-other" принятое в
>>>>> udisks2. Если этот пакет установить, то пользователь получает
>>>>> доступ к устройствам, закреплённым за чужими рабочими местами.
>>>>> Мне кажется, что это ошибка.
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel@lists.altlinux.org
>>>>> https://lists.altlinux.org/mailman/listinfo/devel
>>> _______________________________________________
>>> Devel mailing list
>>> Devel@lists.altlinux.org
>>> https://lists.altlinux.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
WBR, Leonid Krivoshein.