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

[Igor Sysoev]

On Fri, Mar 20, 2009 at 02:47:07PM +0300, Andrei Nigmatulin wrote:

> 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() больше не 
> надо ?

Чтобы при переконфигурации можно было добавлять новые listen на конкретные
адреса. Но операция редкая, я согласен - большинство вполне устраивает
listen *:80.


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