From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Paul Wolneykien To: ALT Linux Team development discussions In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: ALT Linux Date: Wed, 19 Aug 2009 14:56:53 +0400 Message-Id: <1250679413.11189.79.camel@dinkum-thinkum.spb.altlinux.org> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 (2.26.2-alt1) Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?koi8-r?b?U2NyZWVuTG9jayDJIGtlcmJlcm9z?= 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: Wed, 19 Aug 2009 10:57:20 -0000 Archived-At: List-Archive: List-Post: В Срд, 19/08/2009 в 12:03 +0400, Max Ivanov пишет: > Естественно этот файл имеет права 0400, чтобы юзеры не могли его > потырить и использовать в корыстных целях. > > В итоге всё выливается в то, что когда скринсейвер прогоняет пароль > через PAM он делает это от имени пользователя, что ведет к > невозможности его проверки, т.к. /etc/krb5.keytab не доступен на > чтение. Эта проблема касается не только хранителей экрана, но и прочих программ. Например, прокси-сервера squid. Существует по крайней мере 2 общепринятых пути решения этой проблемы: 1. использование вспомогательных программ (helpers), работающих с правами суперпользователя (suid root); 2. использование дополнительного ключевого файла, путь к которому определяется значением переменной KRB5_KTNAME в окружении процесса. В последнем случае использование вспомогательных программ тоже не исключается, однако получаемые ими привилегии ниже, чем у суперпользователя. Возможно, что имеет смысл разработать схему защиты, аналогичную той, которая используется в tcb: для доступа к секретной информации процесс должен обладать привилегиями групп auth и shadow, одна из которых приобретается посредством sgid. Павел.