ra-general-updates: kto, z kim, kiedy ?

[Jakub Bogusz]

On Wed, Dec 11, 2002 at 09:50:01PM +0100, Tomasz Kłoczko wrote:
> On Wed, 11 Dec 2002, Jakub Bogusz wrote:
> > Nawet jeżeli założyć pełne zaufanie do osób mających r/w do CVS - to
> > hasła lecą praktycznie nieszyfrowane (w tej samej postaci, co w .cvspass
> > - jakaś stała mapa).
> > 
> > Chociaż... teraz też nie jest najlepiej - wystarczy trafić w odpowiedni
> > moment i zmodyfikować coś już po puszczeniu zlecenia :/
> 
> Dlatego de facto puszcznie zlecenia musi się wiązać z wczeniejszym
> oetykietowaniem zasobów pakietu i puszczeniem całości z etykiety.
> 
> Typowo wykonuję tu coś takiego:
> 
> $ for i in <lista_speców>; do ./buildrpm_request $i; ./builder -Tvs $i; ./builder -m $i;  done
> 
> Wystarczy odwrócić klejnosć dwuch pierwszysch poleceń w pętli i 
> przechwycić nazwe etykiety jaka zostaął nadana po to zby przekazać to do
> ./buildrpm_request.
> 
> Także ta kwestię uznałbym już za zamkniętą.

A co z możliwością przesunięcia taga przez "osobę niepowołaną"?
Czy tagowanie jest logowane i podlega jakimś restrykcjom (CVSROOT/taginfo)?

Dobrze by było ograniczyć możliwość ustawiania tagów używanych przez
builder tylko dla osób mogących wysyłać zlecenia.

> > BTW, nie wiem czy tak jest na builderach, ale użytkownicy, z których
> > prawami są budowane pakiety, powinni mieć uidy inne niż wszyscy
> > użytkownicy w systemie i innych chrootach (zwłaszcza systemowy użytkownik
> > builder, mający dostęp do sudo chroot, co daje roota).
> 
> Wystarczy w sudoers ograniczyć że chroot musi być wykonany z konkretnymi 
> parametrami żeby wymusić pzrejscie z użytkownika builder po za chroot na 
> użytkownika builder w chroot.
> 
> Przykład:
> 
> builder team=(root) NOPASSWD: /usr/sbin/chroot /home/users/builder/chroot-sparc su - builder

To dopiero po zmianie sposobu dostępu do shella w chroocie (teraz jest
skrypt ~builder/bin/chr, dający roota w chroocie).
Nie wierzę, że dostęp do shella nie będzie nigdy potrzebny - coś się
może wykrzaczyć i trzeba będzie ręcznie poprawiać.
Do przebudowania nowych rzeczy trzeba chwilowo złamać niektóre
zależności (tam, gdzie zwykle trzeba instalować kilka pakietów w jednym
przebiegu).

(przy bootstrapie jeszcze gorzej - po upgrade glibca w chroocie rpm -i/-U
przestaje działać i trzeba robić spoza chroota rpm --root
~builder/chroot-* -U ...)

> Zacznijmu podsumowywać: w nagłówku listu zlecenai powionmny być pola:  
> X-Spec:, X-build-tag:, X-build-arch:, X-build-prioryty:, X-build-commnad: 
> {build|test-build|cancel|staus|install-package|dist-upgrade|remove-package}.

Co do install-package i dist-upgrade - czy/które z nich powinno
obejmować pakiety z /test? (zainstalowanie pakietów z /test na
builderach jest potrzebne przy przygotowywaniu całych zestawów pakietów
do jednoczesnego upgrade - np. (przypadek drastyczny) KDE).


-- 
Jakub Bogusz    http://www.cs.net.pl/~qboosh/