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

[Andrei Nigmatulin]

On Friday 20 March 2009 12:59, Igor Sysoev wrote:
> On Fri, Mar 20, 2009 at 12:48:02PM +0300, Andrei Nigmatulin wrote:
> > On Friday 20 March 2009 12:11, Igor Sysoev wrote:
> > > имеет смысл разрешать только CAP_NET_BIND_SERVICE, потому что,
> > > насколько я понимаю, разрешение CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH и
> > > CAP_CHOWN по сути разрешают делать процессу с файловой системой всё,
> > > что угодно и мало чем отличается от рута. То есть, нужно делать
> > > директиву что-то вроде:
> > >
> > > use_bind_capability;
> > >
> > > которая бы разрешала только CAP_NET_BIND_SERVICE. В этом случае админ
> > > должен сам позабодиться о файлах и прочая: он имеет мастера,
> > > работающего под обычнм пользователем с возможностью bind'иться к 80
> > > порту.
> >
> > А лог файлы переоткрывать хватит прав ?
>
> Нет, о лог-файлах и pid-файле должны позаботиться админ.
>
> В общем, use_bind_capability это возможность работать мастеру не под рутом
> с 80-ым портом. В принципе, это можно распространить на другие OC с тем
> условием, что listen-сокеты могут быть созданы только при запуске первого
> мастера и без возможности добавлять новые при переконфигурации или
> апгрэйде. Учитывая, что многие переконфигурируют методом stop/start,
> потерь в функционалости для них будет немного.

Не понял. Мастер делает bind(), потом сбрасывает привелегии, оставляя 
CAP_NET_BIND_SERVICE ? Зачем, если в процессе работы делать bind() больше не 
надо ?


-- 
Andrei Nigmatulin
GPG PUB KEY 6449830D

Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take