bind chroot

[Robert Luberda]

[środa, 30 sierpień 2000], Jan Rekorajski napisał(a):


> 
> > Btw. W ogóle po co w chroocie umieszczać plik /usr/sbin/named???
> > Przecież /usr/sbin/named uruchomiony przez usera named nie będzie mógł
> > sobie zbindować portu 53.
> 
> /usr/sbin/named jest tam po to że jest zlinkowany statycznie, podobnie
> jak named-xfer.

To po co jest zlinkowany statycznie?

> > 
> > W każdym razie jakiś czas temu instalowałem nameda - ze zwykłych
> > redhatowskich rpm-ów, chrootowałem go i - działa.
> > Konfiguracja jest mniej więcej taka:
> > /var/named 2775 root.named
> > /var/named/slave 775 named.named (pliki w tym katalogu należą do nameda)
> > /var/run 775 named.named (bo named tam wrzuca named.pid)
>  ^^^^^^^^^^^^^^^^^^^^^^^^^ eeee :(

No tak, trochę się pomyliłem, /var/run jest root.named 775.
Wprawdzie po starcie named sobie tworzy tam plik named.pid
jako root, ale jak wyślę namedowi HUP-a, to kasuje ten plik i tworzy 
nowy z taką samą zawartością. Nie wiem, po co mu to...

> 
> IMHO wszystko, pi razy uprawnienia do /usr/sbin/* w chroocie jest ok.

IMHO nie. User named na pewno nie musi być ownerem /var/lib/named/chroot/{etc,dev,usr},
samego /var/lib/named/chroot i plików tam się znajdujących.
Te katalogi powinny mieć minimalne prawa root.named 750.

Btw. Przejrzałem speca do bind'a i w sekcji files  niechrootowanego
pakietu jest /var/lib/named/M jest %attr(750,root,root).

> BTW, ja to brałem z pakietu bind-chroot z redhat-contrib.

Hmmm. Pakiety z redhat-contrib niekoniecznie należą do najlepiej
przygotowanych...



Pozdrawiam

Robert

-- 
Robert Luberda
robert w pingu.ii.uj.edu.pl


___________________________
polish  linux  distribution
-> http://lists.pld.org.pl/