From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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> <20240928005714.5278d068@legato> Content-Language: ru, en-US From: Leonid Krivoshein 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 List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2024 22:46:45 -0000 Archived-At: List-Archive: List-Post: On 9/28/24 00:57, Paul Wolneykien wrote: > В Fri, 27 Sep 2024 22:52:29 +0300 > Leonid Krivoshein пишет: > >> Привет! >> >> >> On 9/27/24 15:18, Paul Wolneykien wrote: >>> В Fri, 27 Sep 2024 14:54:31 +0300 >>> Danil Shein пишет: >>> >>>> Интересное исследование. >>>> И вы наверняка затронули актуальную для вас проблему. >>>> >>>> Однако в моём поле зрения уже много лет нет ни одного компьютера с >>>> оптическим приводом вообще. >>> По мне, так сам принцип временной (!) смены 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.