Re: [PATCH 2/2] Setting more capabilities(CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH and CAP_SETUID).

[Igor Sysoev <is@xxxxxxxxxxxxx>]

On Fri, Mar 20, 2009 at 09:15:42AM +0200, Alex Vorona wrote:

> 20.03.2009 07:50, Igor Sysoev wrote:
> 
> >И вообще, эти capabilities где-нибудь документированы ? Я с ходу не нашёл,
> >что означают CAP_EFFECTIVE, CAP_PERMITTED и CAP_INHERITABLE.
> >
> Нашёл на 
> http://www.ibm.com/developerworks/ru/library/l-posixcap/l-posixcap.html
> >Каждый процесс имеет три набора прав доступа: доступные (permitted) (P), 
> >наследуемые (inheritable) (I) и текущие (effective) (E)
> 
> Похоже, это оно.

Спасибо. Лучше правда читать оригинал:
http://www.ibm.com/developerworks/linux/library/l-posixcap.html

потому что вот это:

Call prctl(2) to set PR_SET_KEEPCAPS, which asks the system to let
it keep its capabilities across setuid(2). 

явно не означает:

Вызвать prctl(2), чтобы установить PR_SET_KEEPCAPS, который через
setuid(2) запрашивает систему о сохранении его разрешений. 

Судя по capabilities(7):

http://www.freebsd.org/cgi/man.cgi?query=capabilities&apropos=0&sektion=0&manpath=SuSE+Linux%2Fi386+ES+10+SP1&format=ascii

имеет смысл разрешать только CAP_NET_BIND_SERVICE, потому что, насколько
я понимаю, разрешение CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH и CAP_CHOWN
по сути разрешают делать процессу с файловой системой всё, что угодно
и мало чем отличается от рута. То есть, нужно делать директиву что-то вроде:

use_bind_capability;

которая бы разрешала только CAP_NET_BIND_SERVICE. В этом случае админ
должен сам позабодиться о файлах и прочая: он имеет мастера, работающего
под обычнм пользователем с возможностью bind'иться к 80 порту.


-- 
Игорь Сысоев
http://sysoev.ru