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=1727466755; x=1728071555; 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=MA4E1YrhVLDRv/xdLFeKmVAUieboOl01VLhV1IU9kUk=; b=iBdtTktl7pi8wzwg2SToBgHdxtiYffLWFz3w++YiTH7H06yUjp/XskwAZ5B5LDir5v pFUdPZT2b+EG0UPvBSu71TC7bDMX/dMZNTDLPrOclxzDwX/ptSMXUau9NAta5d0Iq3CQ ZlUvBWDsxHItPavmvpHXKVHTkeXlp0h1XPwgPubA84/P4za7lHzeDolqCTVwPjPIXUWd r0Qzu7sdYNoky/x8zH43abdbHWDj4Sk5L/c9B9cJeL3JZJ2F/glKCmvhwM7XsOVbgIQ6 q8o6S3v4PWlTe7d/88yL5vxrXOmwkX50qXwmnW1BWYWNojfMQDHHzdDYhc3xPPcnrAA0 Ll6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727466755; x=1728071555; 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=MA4E1YrhVLDRv/xdLFeKmVAUieboOl01VLhV1IU9kUk=; b=Zcsn7IXbUgAJI+eSiIxtMWYodv4jnEb+eb+r4ryPvgcV9kRIVcTVdtrr66swQy0Nfw 5yceX3rTuVmbGq7CcFWExDKK8t799dGpg2GeobfQ3mMyBHdh7GC36rTa81I70iI7I/UI zYajKovSZTvzrefXQapUvyrajy+gdJ2REgowDVyOmq19TQGl0ByWDxttkkot9diAORem lZp1/0XGRQLykMmAbcyWfdEsOAYjL0GOrl2Tyj++rmuNhmiFv6Tp7icj/mvAAvyz7+hN VmwB0mCvtYKnS8NGnjtSh39KGjOCB+3DVKvmGfANJndf6IBpbW/IF5V7Y/3fawNuYx4F rs2g== X-Gm-Message-State: AOJu0YzL3p7JGfqy5oxBUBPvosDv4GDbB4wZab38SlJ+cHrjYQVjwxNJ BO277uWHqfvp1onygBqQoK+VRB16ZRXWI5hsMa0r4+dPFyXmwBL34jR3NQ== X-Google-Smtp-Source: AGHT+IEZOI64kJH8+sMTo8kL0HvK0Nh0SeWH+0GF4Dgnt2kWsU0r/xlPOFnTav76H6ltax1iZPzOUA== X-Received: by 2002:a2e:6112:0:b0:2f7:c215:4f33 with SMTP id 38308e7fff4ca-2f9d41a1c0cmr22276371fa.27.1727466754390; Fri, 27 Sep 2024 12:52:34 -0700 (PDT) Message-ID: Date: Fri, 27 Sep 2024 22:52:29 +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> Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: <20240927151805.12b8ec11@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 19:52:42 -0000 Archived-At: List-Archive: List-Post: Привет! 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, эта парочка обеспечит любые права независимо от прав пользователя на устройство. Плюс: опции пользовательского монтирования в /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 -- WBR, Leonid Krivoshein.